yes, sorry, was actually quite well formatted (clang-format default) ... but its probably just me working on the code ever. So, i will just use my preferences here.
I find it important. visual guy and all other excuses...
Highlights all the output message operators when banged.
The H operator shouldn't have an output port but a right-side-locked
port type, and has been modified.
The 'tool' build script previously required bash. This commit changes it
to need only POSIX sh, which removes a dependency from the project. bash
is a bit easier to work with than POSIX sh, but the trade-off seems
worth it in this case. We already require POSIX, so we're guaranteed to
have access to POSIX sh. Some systems may not have bash.
As an added bonus, the startup time of the script will probably be
slightly faster by a few milliseconds, because some implementations like
dash start up faster than bash.
One downside is that POSIX sh doesn't have a built-in for 'time', and
one of my testing environments, a stripped-down Ubuntu image, didn't
have 'time' installed by default. I believe 'time' is mandatory in
POSIX, so that's a bit strange. I think this might be a common thing, so
I added a case to handle it in the 'tool' script, instead of having the
script fail.
Previously, the Qnav blocks (the menu panels) would have their position
determined once when they're first created, and then never updated. The
positioning of Qnav blocks is determined by some code that may cause the
blocks to wrap or be positioned differently depending on how much screen
space is available. For example, if you open a nested menu that's three
blocks/panels deep, and the third panel doesn't have enough room on the
right in the terminal, it may be shown below the second panel instead of
to the right.
This had a flaw. If the user resized their terminal after the menus were
already open, the positions of the menu panels wouldn't be adjusted to
accommodate the new screen size. There wasn't a way to trigger a full
re-layout of all the menu items when the terminal was resized.
This commit adds qnav_adjust_term_size(), which is called from
tui_main.c when the terminal is resized. This function will re-layout
the menu panels.
An oversight in the implementation of J and Y meant that the chain would
grow each frame, if there were at least two segments and the first
segment was locked by something like H. Example:
H
YY
This is not what we want. I've added a guard in the J and Y
implementations that checks if the glyph above (or for Y, to the left)
is an earlier part of the chain, and if it is, to return. This has the
downside of making long chains potentially having to enter the J code
repeatedly, only to end up doing nothing.
The STUN() in J and Y might no longer be worth it. It was used to
prevent further operators in the chain from running, but since we have a
guard now, the writes while looping might end up costing more time.
We don't have any good benchmark files set up right now, so we'll have
to test it in the future.
I had believed this case was working correctly, but an edit to reduce
the number of used local variables had introduced a mistake that caused
it to fail. This commit fixes the problem by overwriting the variable
where the captured output of a failed pkg-config attempt was stored with
0, so that the subsequent if branch works correctly.
Depending on the Linux distro, ncurses may be built with tinfo as a
separate library that needs to be explicitly linked, or it may not.
Trying to pass -ltinfo when you don't need to might cause a linking
error. Failing to pass -ltinfo when you need to might cause a linking
error. And you might need to pass -ltinfow instead of -ltinfo, or you
might not. And if you get that wrong, you might cause a linking error.
This commit adds use pkg-config to the tool build script, attempting to
discover what args to use. This is only done on Linux. On other
platforms, or if pkg-config returns an error, we use the same hard-coded
options as before: -lncursesw -lformw
This probably adds about 5 or 10 milliseconds to the execution time of
the tool script.
J and Y and now be chained (like YYYYYY) to copy a glyph across the
'wire' they form.
This is a simple implementation of the feature. This changes both J and Y to
have loops in their definitions, instead of being single reads and
writes, which will make them heavier and have a adverse effect on
benchmarks. It also makes it harder to explain how orca's VM works,
since these operators are now non-trivial and can't be used as examples
of trivial operators. But we've decided it's worth it.
Qform (the popup text entry thing) is currently only used as a single
modal text input, but the TUI code still went through the motions of
setting each one up as if it could have a variety of things inside of
it. This commit saves on repeated code by providing a wrapper that does
the thing we want, but still leaves the door open in the future for
having other types of inputs in the form.
It also renames a few Qform functions for consistency.
This attribute macro, ORCA_OPT_MINSIZE, isn't currently in use in any of
the code, though it occasionally gets used when testing things. I had
previously only tested this under clang, and hadn't tested it under gcc.
Some of the syntax was missing for gcc's version. This commit fixes it.
This removes the limitation of having a hard-coded maximum number of
entries. There is no cost to code size. Iteration speed across Qnav
blocks may be slightly slower, because the elements are allocated in
arbitrary heap locations, which may prevent the next item from being
prefetched across links. But, there are rarely more than 3 entries, and
most of the time there are 0 entries. Iteration occurs only when
redrawing the Qnav blocks and when quitting.
We use a doubly linked list instead of singly linked because we need
quick access to the top entry while also needing to iterate from the
bottom to top when drawing the entries.
An equivalent implementation with a stretchy/dynamic array of pointers
was made, but the code size was larger and required more error checks
and an extra heap allocation.
A theoretical implementation that wants to reduce heap fragmentation
could use a contiguous or slab allocation of multiple Qnav blocks/items.
This would probably require more code, but may be worth it if this
menuing/widget system is extended for reuse across projects in the
future.
For now, we separately heap allocate each Qnav item and link them
together. Not great, but we don't have to worry about picking an
arbitrary count for an array of pointers, and we aren't increasing the
code size or complexity. Those are important things for this project.
This commit implements the Qnav/Qmenu system directly in ncurses,
replacing the old implementation which relied on the 'menu' library.
The new code is shorter, easier to read, and doesn't need the 'menu'
library to be linked.
For users, the behavior of the menus should be the same.
We still rely on the 'form' library for text field input in the menus.
heck