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

1883 lines
46 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] 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
qwaq-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"
#include "qwaq.h"
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
#include "qwaq-curses.h"
[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
#include "qwaq-rect.h"
#include "qwaq-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] 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 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] 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 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",
"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 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)
{
PR_RESNEW (window_t, res->window_map);
}
static void
window_free (qwaq_resources_t *res, window_t *win)
{
PR_RESFREE (window_t, res->window_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
window_reset (qwaq_resources_t *res)
{
PR_RESRESET (window_t, res->window_map);
}
static inline window_t *
window_get (qwaq_resources_t *res, unsigned index)
{
PR_RESGET(res->window_map, index);
}
static inline int
window_index (qwaq_resources_t *res, window_t *win)
{
PR_RESINDEX (res->window_map, win);
}
[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] Fix some more formatLine cases I think this is all of them. Scrolling around in a file, including having the end of file visible in the window, seems to work well.
2020-03-22 14:50:27 +00:00
PR_RunError (res->pr, "invalid window passed to %s", 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)
{
PR_RESNEW (panel_t, res->panel_map);
}
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
{
[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
PR_RESFREE (panel_t, 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
{
[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
PR_RESRESET (panel_t, res->panel_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
[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)
{
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
}
[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 int
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
{
[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
PR_RESINDEX (res->panel_map, win);
}
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
acquire_string (qwaq_resources_t *res)
{
int string_id = -1;
[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
pthread_mutex_lock (&res->string_id_cond.mut);
[qwaq] Correct some queue test logic This fixes the wedge during initial setup and drawing, but the program deadlocks when processing input and there's an event.
2020-03-21 03:02:35 +00:00
while (RB_DATA_AVAILABLE (res->string_ids) < 1) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_wait (&res->string_id_cond.rcond,
[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
&res->string_id_cond.mut);
[qwaq] Get DrawBuffer and TextContext working Especially blitting whole regions. Partial regions not tested yet.
2020-03-12 17:09:55 +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
RB_READ_DATA (res->string_ids, &string_id, 1);
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->string_id_cond.wcond);
[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
pthread_mutex_unlock (&res->string_id_cond.mut);
[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
return 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
}
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
release_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] 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
pthread_mutex_lock (&res->string_id_cond.mut);
[qwaq] Correct some queue test logic This fixes the wedge during initial setup and drawing, but the program deadlocks when processing input and there's an event.
2020-03-21 03:02:35 +00:00
while (RB_SPACE_AVAILABLE (res->string_ids) < 1) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_wait (&res->string_id_cond.wcond,
[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
&res->string_id_cond.mut);
[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] 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
RB_WRITE_DATA (res->string_ids, &string_id, 1);
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->string_id_cond.rcond);
[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
pthread_mutex_unlock (&res->string_id_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] 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
static void
qwaq_submit_command (qwaq_resources_t *res, const int *cmd)
{
unsigned len = cmd[1];
[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
pthread_mutex_lock (&res->command_cond.mut);
while (RB_SPACE_AVAILABLE (res->command_queue) < len) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_wait (&res->command_cond.wcond,
[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
&res->command_cond.mut);
[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] 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
RB_WRITE_DATA (res->command_queue, cmd, len);
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->command_cond.rcond);
[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
pthread_mutex_unlock (&res->command_cond.mut);
[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
}
static void
qwaq_submit_result (qwaq_resources_t *res, const int *result, unsigned len)
{
[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
pthread_mutex_lock (&res->results_cond.mut);
while (RB_SPACE_AVAILABLE (res->results) < len) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_wait (&res->results_cond.wcond,
[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
&res->results_cond.mut);
[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] 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
RB_WRITE_DATA (res->results, result, len);
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->results_cond.rcond);
[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
pthread_mutex_unlock (&res->results_cond.mut);
[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
}
static void
qwaq_wait_result (qwaq_resources_t *res, int *result, int cmd, unsigned len)
{
[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
pthread_mutex_lock (&res->results_cond.mut);
while (RB_DATA_AVAILABLE (res->results) < len
[qwaq] Fix missed logic conversion
2020-03-21 02:36:24 +00:00
|| RB_PEEK_DATA (res->results, 0) != cmd) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_wait (&res->results_cond.rcond,
[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
&res->results_cond.mut);
[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] 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
RB_READ_DATA (res->results, result, len);
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->results_cond.wcond);
[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
pthread_mutex_unlock (&res->results_cond.mut);
[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
}
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] 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 = RB_PEEK_DATA (res->command_queue, 2);
int ypos = RB_PEEK_DATA (res->command_queue, 3);
int xlen = RB_PEEK_DATA (res->command_queue, 4);
int ylen = RB_PEEK_DATA (res->command_queue, 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] 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_submit_result (res, 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
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
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] 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_submit_result (res, 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
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
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] 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_submit_result (res, 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
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
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)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
hide_panel (panel->panel);
}
static void
cmd_show_panel (qwaq_resources_t *res)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
show_panel (panel->panel);
}
static void
cmd_top_panel (qwaq_resources_t *res)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
top_panel (panel->panel);
}
static void
cmd_bottom_panel (qwaq_resources_t *res)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
bottom_panel (panel->panel);
}
static void
cmd_move_panel (qwaq_resources_t *res)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
int x = RB_PEEK_DATA (res->command_queue, 3);
int y = RB_PEEK_DATA (res->command_queue, 4);
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)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
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] 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_submit_result (res, 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)
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
int window_id = RB_PEEK_DATA (res->command_queue, 3);
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] 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 = RB_PEEK_DATA (res->command_queue, 2);
int x = RB_PEEK_DATA (res->command_queue, 3);
int y = RB_PEEK_DATA (res->command_queue, 4);
int string_id = RB_PEEK_DATA (res->command_queue, 5);
window_t *window = get_window (res, __FUNCTION__, window_id);
mvwaddstr (window->win, y, x, res->strings[string_id].str);
release_string (res, 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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int string_id = RB_PEEK_DATA (res->command_queue, 3);
window_t *window = get_window (res, __FUNCTION__, window_id);
waddstr (window->win, res->strings[string_id].str);
release_string (res, string_id);
}
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
static void
cmd_mvwaddch (qwaq_resources_t *res)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int x = RB_PEEK_DATA (res->command_queue, 3);
int y = RB_PEEK_DATA (res->command_queue, 4);
int ch = RB_PEEK_DATA (res->command_queue, 5);
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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int ch = RB_PEEK_DATA (res->command_queue, 3);
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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
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)
{
int pair = RB_PEEK_DATA (res->command_queue, 2);
int f = RB_PEEK_DATA (res->command_queue, 3);
int b = RB_PEEK_DATA (res->command_queue, 4);
init_pair (pair, f, b);
}
static void
cmd_wbkgd (qwaq_resources_t *res)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int ch = RB_PEEK_DATA (res->command_queue, 3);
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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int flag = RB_PEEK_DATA (res->command_queue, 3);
window_t *window = get_window (res, __FUNCTION__, window_id);
scrollok (window->win, flag);
}
[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)
{
int x = RB_PEEK_DATA (res->command_queue, 2);
int y = RB_PEEK_DATA (res->command_queue, 3);
move (y, x);
}
static void
cmd_curs_set (qwaq_resources_t *res)
{
int visibility = RB_PEEK_DATA (res->command_queue, 2);
curs_set (visibility);
}
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
static void
cmd_wborder (qwaq_resources_t *res)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int ls = RB_PEEK_DATA (res->command_queue, 3);
int rs = RB_PEEK_DATA (res->command_queue, 4);
int ts = RB_PEEK_DATA (res->command_queue, 5);
int bs = RB_PEEK_DATA (res->command_queue, 6);
int tl = RB_PEEK_DATA (res->command_queue, 7);
int tr = RB_PEEK_DATA (res->command_queue, 8);
int bl = RB_PEEK_DATA (res->command_queue, 9);
int br = RB_PEEK_DATA (res->command_queue, 10);
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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int x = RB_PEEK_DATA (res->command_queue, 3);
int y = RB_PEEK_DATA (res->command_queue, 4);
int chs_id = RB_PEEK_DATA (res->command_queue, 5);
int len = RB_PEEK_DATA (res->command_queue, 6);
int *chs = (int *) res->strings[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);
release_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
}
[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)
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int width = RB_PEEK_DATA (res->command_queue, 3);
int height = RB_PEEK_DATA (res->command_queue, 4);
window_t *window = get_window (res, __FUNCTION__, window_id);
wresize (window->win, height, width);
}
static void
cmd_resizeterm (qwaq_resources_t *res)
{
int width = RB_PEEK_DATA (res->command_queue, 2);
int height = RB_PEEK_DATA (res->command_queue, 3);
resizeterm (height, width);
}
[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] Add support for invisible buttons Useful for window controls.
2020-03-23 13:00:05 +00:00
if (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
qwaq_commands cmd = RB_PEEK_DATA (res->command_queue, 0);
Sys_Printf ("%s[%d]", qwaq_command_names[cmd], len);
for (int i = 2; i < len; i++) {
Sys_Printf (" %d", RB_PEEK_DATA (res->command_queue, i));
}
Sys_Printf ("\n");
}
}
[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
void
qwaq_init_timeout (struct timespec *timeout, long time)
[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] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
#define SEC 1000000000L
[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 timeval now;
gettimeofday(&now, 0);
timeout->tv_sec = now.tv_sec;
[qwaq] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
timeout->tv_nsec = now.tv_usec * 1000L + time;
[qwaq] Actually ensure tv_nsec is valid While typing the previous message I thought to check my "carry" logic. Sure enough, it was wrong... out by 1. I guess I won the threading lottery :P
2020-03-21 23:40:51 +00:00
if (timeout->tv_nsec >= SEC) {
[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
timeout->tv_sec += timeout->tv_nsec / SEC;
timeout->tv_nsec %= SEC;
}
}
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;
pthread_mutex_lock (&res->command_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] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
while (RB_DATA_AVAILABLE (res->command_queue) < 2 && ret == 0) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
ret = pthread_cond_timedwait (&res->command_cond.rcond,
[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
&res->command_cond.mut, &timeout);
}
pthread_mutex_unlock (&res->command_cond.mut);
while ((avail = RB_DATA_AVAILABLE (res->command_queue)) >= 2
&& avail >= (len = RB_PEEK_DATA (res->command_queue, 1))) {
dump_command (res, len);
[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
qwaq_commands cmd = RB_PEEK_DATA (res->command_queue, 0);
switch (cmd) {
[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 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] 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] 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
pthread_mutex_lock (&res->command_cond.mut);
RB_DROP_DATA (res->command_queue, len);
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->command_cond.wcond);
[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
pthread_mutex_unlock (&res->command_cond.mut);
[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] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
static int
get_event (qwaq_resources_t *res, qwaq_event_t *event)
{
[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 ret = 0;
[qwaq] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
int was_event = 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
pthread_mutex_lock (&res->event_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] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
while (RB_DATA_AVAILABLE (res->event_queue) < 1 && ret == 0) {
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
ret = pthread_cond_timedwait (&res->event_cond.rcond,
[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
&res->event_cond.mut, &timeout);
}
if (event) {
[qwaq] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
if (ret == 0) {
[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
RB_READ_DATA (res->event_queue, event, 1);
[qwaq] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
was_event = 1;
Implement mouse auto events These are for when a button is held down: good for scroll bar arrows etc.
2020-03-22 05:06:27 +00:00
} else if (res->button_state) {
event->what = qe_mouseauto;
event->mouse.buttons = res->button_state;
event->mouse.x = res->mouse_x;
event->mouse.y = res->mouse_y;
[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
} else {
event->what = qe_none;
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
}
}
[qwaq] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_broadcast (&res->event_cond.wcond);
[qwaq] Actually unlock the event queue mutex And now everything works as well threaded as it did unthreaded.
2020-03-21 03:46:22 +00:00
pthread_mutex_unlock (&res->event_cond.mut);
[qwaq] Be a little paranoid about cond wait timeouts I'd left qwaq-curses running overnight and found it locked up: both threads were looping because pthread_cond_timedwait was returning EINVAL. Thus bail if anything other than 0 is returned, and try to ensure tv_nsec is in the range 0..999999999
2020-03-21 23:35:37 +00:00
return was_event;
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +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
{
[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
__auto_type pr = (progs_t *) _pr;
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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] 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_input_shutdown (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
endwin ();
}
}
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
bi_newwin (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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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] 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_submit_command (res, command);
[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_wait_result (res, cmd_result, qwaq_cmd_newwin, CMD_SIZE (cmd_result));
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
[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
bi_delwin (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_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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] 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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_getwrect, 0, window_id, };
command[1] = CMD_SIZE(command);
[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_submit_command (res, command);
int cmd_result[5];
qwaq_wait_result (res, cmd_result, qwaq_cmd_getwrect,
CMD_SIZE (cmd_result));
// 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
[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
bi_new_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_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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] 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_submit_command (res, command);
[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_wait_result (res, cmd_result, qwaq_cmd_new_panel,
CMD_SIZE (cmd_result));
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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] 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_submit_command (res, command);
[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
[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
bi_del_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_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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] 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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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] 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_submit_command (res, command);
[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_wait_result (res, cmd_result, qwaq_cmd_panel_window,
CMD_SIZE (cmd_result));
(&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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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_submit_command (res, command);
}
}
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
int command[] = { qwaq_cmd_update_panels, 0, };
command[1] = CMD_SIZE(command);
[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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
int command[] = { qwaq_cmd_doupdate, 0, };
command[1] = CMD_SIZE(command);
[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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
int command[] = {
qwaq_cmd_waddstr, 0,
window_id, string_id
};
command[1] = CMD_SIZE(command);
dstring_copystr (print_buffer, str);
qwaq_submit_command (res, command);
}
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = {
qwaq_cmd_wresize, 0,
window_id, width, height
};
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, command);
}
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
int command[] = { qwaq_cmd_resizeterm, 0, width, height };
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, command);
}
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 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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
int command[] = {
qwaq_cmd_mvwaddstr, 0,
window_id, x, y, string_id
};
command[1] = CMD_SIZE(command);
dstring_copystr (print_buffer, str);
qwaq_submit_command (res, command);
}
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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)) {
int string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
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_submit_command (res, command);
}
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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] 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 string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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)) {
int string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_waddch, 0, window_id, ch };
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, command);
}
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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)) {
int string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
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_submit_command (res, command);
}
}
[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_mvwvprintf (pr, x, y, window_id, fmt, args);
}
static void
qwaq_mvwaddch (progs_t *pr, int window_id, int x, int y, int ch)
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
[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_submit_command (res, 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
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_wrefresh, 0, window_id, };
command[1] = CMD_SIZE(command);
[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_submit_command (res, command);
[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 an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
static void
bi_get_event (progs_t *pr)
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
qwaq_event_t *event = &G_STRUCT (pr, qwaq_event_t, P_INT (pr, 0));
R_INT (pr) = get_event (res, event);
}
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
int command[] = { qwaq_cmd_init_pair, 0, pair, f, b, };
command[1] = CMD_SIZE(command);
[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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_wbkgd, 0, window_id, ch, };
command[1] = CMD_SIZE(command);
[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_submit_command (res, command);
[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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_werase, 0, window_id, };
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, command);
}
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_scrollok, 0, window_id, flag, };
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, 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
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 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_resources_t *res = PR_Resources_Find (pr, "qwaq");
int command[] = { qwaq_cmd_move, 0, x, y, };
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, 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
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
int command[] = { qwaq_cmd_curs_set, 0, visibility, };
command[1] = CMD_SIZE(command);
qwaq_submit_command (res, 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
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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_submit_command (res, 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
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
if (get_window (res, __FUNCTION__, window_id)) {
int chs_id = acquire_string (res);
dstring_t *chs_buf = res->strings + chs_id;
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_submit_command (res, command);
}
}
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);
[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_process_input (res);
[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
}
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_resources_t *res = PR_Resources_Find (pr, "qwaq");
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);
[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_input_init (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
refresh();
[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
bi_c_TextContext__is_initialized (progs_t *pr)
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
R_INT (pr) = res->initialized;
}
static void
bi_c_TextContext__max_colors (progs_t *pr)
{
bi_max_colors (pr);
}
static void
bi_c_TextContext__max_color_pairs (progs_t *pr)
{
bi_max_color_pairs (pr);
}
static void
bi_c_TextContext__init_pair_ (progs_t *pr)
{
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
bi_c_TextContext__acs_char_ (progs_t *pr)
{
int acs = P_INT (pr, 2);
qwaq_acs_char (pr, acs);
}
static void
bi_c_TextContext__move_ (progs_t *pr)
{
Point *pos = &P_PACKED (pr, Point, 2);
qwaq_move (pr, pos->x, pos->y);
}
static void
bi_c_TextContext__curs_set_ (progs_t *pr)
{
int visibility = P_INT (pr, 2);
qwaq_curs_set (pr, visibility);
}
static void
bi_c_TextContext__doupdate (progs_t *pr)
{
bi_doupdate (pr);
}
static void
bi_i_TextContext__mvprintf_ (progs_t *pr)
{
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
bi_i_TextContext__printf_ (progs_t *pr)
{
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
[qwaq] Fixed swapped method implementations That was fun
2020-03-08 13:21:15 +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
[qwaq] Fixed swapped method implementations That was fun
2020-03-08 13:21:15 +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
bi_i_TextContext__addstr_ (progs_t *pr)
{
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
bi_i_TextContext__mvvprintf_ (progs_t *pr)
{
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);
__auto_type args = (pr_va_list_t *) &P_POINTER (pr, 4);
qwaq_mvwvprintf (pr, pos->x, pos->y, window_id, fmt, args);
}
[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_i_TextContext__resizeTo_ (progs_t *pr)
{
__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
bi_c_TextContext__refresh (progs_t *pr)
{
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
bi_i_TextContext__refresh (progs_t *pr)
{
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_wrefresh (pr, window_id);
qwaq_update_panels (pr);
if (window_id == 1) {
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
bi_i_TextContext__mvaddch_ (progs_t *pr)
{
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
bi_i_TextContext__mvaddstr_ (progs_t *pr)
{
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
bi_i_TextContext__bkgd_ (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;
[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
bi_i_TextContext__clear (progs_t *pr)
{
[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
bi_i_TextContext__scrollok_ (progs_t *pr)
{
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
bi_i_TextContext__border_ (progs_t *pr)
{
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);
}
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
bi_qwaq_clear (progs_t *pr, void *data)
{
__auto_type res = (qwaq_resources_t *) data;
if (res->initialized) {
[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_input_shutdown (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
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
}
static builtin_t builtins[] = {
{"initialize", bi_initialize, -1},
[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
{"create_window", bi_newwin, -1},
{"destroy_window", bi_delwin, -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
{"getwrect", bi_getwrect, -1},
[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
{"create_panel", bi_new_panel, -1},
{"destroy_panel", bi_del_panel, -1},
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
{"hide_panel", bi_hide_panel, -1},
{"show_panel", bi_show_panel, -1},
{"top_panel", bi_top_panel, -1},
{"bottom_panel", bi_bottom_panel, -1},
{"move_panel", bi_move_panel, -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
{"panel_window", bi_panel_window, -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
{"replace_panel", bi_replace_panel, -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
{"update_panels", bi_update_panels, -1},
{"doupdate", bi_doupdate, -1},
[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
{"mvwprintf", bi_mvwprintf, -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
{"wprintf", bi_wprintf, -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
{"wvprintf", bi_wvprintf, -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
{"mvwvprintf", bi_mvwvprintf, -1},
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
{"mvwaddch", bi_mvwaddch, -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
{"waddch", bi_waddch, -1},
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
{"mvwaddstr", bi_mvwaddstr, -1},
{"waddstr", bi_waddstr, -1},
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
{"wrefresh", bi_wrefresh, -1},
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
{"get_event", bi_get_event, -1},
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
{"max_colors", bi_max_colors, -1},
{"max_color_pairs", bi_max_color_pairs, -1},
{"init_pair", bi_init_pair, -1},
{"wbkgd", bi_wbkgd, -1},
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
{"werase", bi_werase, -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
{"scrollok", bi_scrollok, -1},
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
{"acs_char", bi_acs_char, -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
{"move", bi_move, -1},
{"curs_set", bi_curs_set, -1},
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
{"wborder", bi_wborder, -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
{"mvwblit_line", bi_mvwblit_line, -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
{"wresize", bi_wresize, -1},
{"resizeterm", bi_resizeterm, -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
{"_c_TextContext__is_initialized", bi_c_TextContext__is_initialized, -1},
{"_c_TextContext__max_colors", bi_c_TextContext__max_colors, -1},
{"_c_TextContext__max_color_pairs", bi_c_TextContext__max_color_pairs, -1},
{"_c_TextContext__init_pair_", bi_c_TextContext__init_pair_, -1},
{"_c_TextContext__acs_char_", bi_c_TextContext__acs_char_, -1},
{"_c_TextContext__move_", bi_c_TextContext__move_, -1},
{"_c_TextContext__curs_set_", bi_c_TextContext__curs_set_, -1},
{"_c_TextContext__doupdate", bi_c_TextContext__doupdate, -1},
{"_i_TextContext__mvprintf_", bi_i_TextContext__mvprintf_, -1},
{"_i_TextContext__printf_", bi_i_TextContext__printf_, -1},
{"_i_TextContext__vprintf_", bi_i_TextContext__vprintf_, -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
{"_i_TextContext__addch_", bi_i_TextContext__addch_, -1},
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
{"_i_TextContext__addstr_", bi_i_TextContext__addstr_, -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
{"_i_TextContext__mvvprintf_", bi_i_TextContext__mvvprintf_, -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
{"_i_TextContext__resizeTo_", bi_i_TextContext__resizeTo_, -1},
[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
{"_c_TextContext__refresh", bi_c_TextContext__refresh, -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
{"_i_TextContext__refresh", bi_i_TextContext__refresh, -1},
{"_i_TextContext__mvaddch_", bi_i_TextContext__mvaddch_, -1},
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
{"_i_TextContext__mvaddstr_", bi_i_TextContext__mvaddstr_, -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
{"_i_TextContext__bkgd_", bi_i_TextContext__bkgd_, -1},
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
{"_i_TextContext__clear", bi_i_TextContext__clear, -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
{"_i_TextContext__scrollok_", bi_i_TextContext__scrollok_, -1},
{"_i_TextContext__border_", bi_i_TextContext__border_, -1},
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}
};
[qwaq] Use a log file instead of stderr Now I don't have to worry about remembering to redirect the output, but debugging is still easy.
2020-03-06 09:29:16 +00:00
static FILE *logfile;
[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 __attribute__((format(printf, 1, 0))) void
qwaq_print (const char *fmt, va_list args)
{
[qwaq] Use a log file instead of stderr Now I don't have to worry about remembering to redirect the output, but debugging is still easy.
2020-03-06 09:29:16 +00:00
vfprintf (logfile, fmt, args);
fflush (logfile);
[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] Make qwaq_cond_init public
2020-03-24 10:48:57 +00:00
void
[qwaq] Rename cond_t to rwcond_t
2020-03-24 10:48:20 +00:00
qwaq_init_cond (rwcond_t *cond)
[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] Use separate conditions for queue read/write While writing the code I suspected this would be necessary, but it's nice to know. Now the window seems to be correctly fetched, but get_event locks up.
2020-03-21 02:39:55 +00:00
pthread_cond_init (&cond->rcond, 0);
pthread_cond_init (&cond->wcond, 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
pthread_mutex_init (&cond->mut, 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
BI_Init (progs_t *pr)
{
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] 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
for (int i = 0; i < STRING_ID_QUEUE_SIZE - 1; i++) {
RB_WRITE_DATA (res->string_ids, &i, 1);
res->strings[i].mem = &dstring_default_mem;
}
[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
res->escbuff.mem = &dstring_default_mem;
// ensure the backing buffer exists
dstring_clearstr (&res->escbuff);
[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_init_cond (&res->event_cond);
qwaq_init_cond (&res->command_cond);
qwaq_init_cond (&res->results_cond);
qwaq_init_cond (&res->string_id_cond);
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
PR_Resources_Register (pr, "qwaq", res, bi_qwaq_clear);
PR_RegisterBuiltins (pr, builtins);
[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);
[qwaq] Use a log file instead of stderr Now I don't have to worry about remembering to redirect the output, but debugging is still easy.
2020-03-06 09:29:16 +00:00
logfile = fopen ("qwaq-curses.log", "wt");
[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
Sys_SetStdPrintf (qwaq_print);
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