Looking for thoughts on a library architecture decision

[ZeroByte]

I'm currently developing a C library/API for a widgets engine to be used in C, and I'm really on the fence about one design decision, so I thought I'd see what others might have to say.

The system uses signals like SIG_ENABLE / SIG_TIMERTICK / SIG_INPUT / SIG_DRAW / etc, and it keeps a set of bit flags in a register called "state".

One of these flags is VISIBLE and one is a "dirty bit" indicating the widget needs to be redrawn on the next pass.

So here's the question: In the API function draw_widget(id), one of the checks is whether the widget's ACTIVE and VISIBLE flags are set.

Would it make more sense for the draw_widget(id) function to imply that you want the widget to be set ACTIVE and VISIBLE if you call it, or for it to basically perform a NOOP if the widget is not active and visible?

I do have hide/show API calls, and enable/disable API calls already, so I'm kind of leaning towards the NOOP side of this.

I can see there being a need for a force_draw() API call as well which works on visible but disabled widgets. (suppose the program switched the screen to something else, and then when it comes back to the widgets, it would need to redraw them all, even if disabled)

This seems to be the best idea to me: (adding a force_draw() routine and having the basic draw() routine only work if the widget is already active and visible)

I've got plenty of code modules to be working on, so I'm going to let it sit as currently implemented (api_draw() only works on active and visible widgets and does not cause widgets to BECOME active and visible if they aren't already that way)

[Scott Robison]

Typically visible is a either draw it or not flag, and disabled is "allow it to be shown if visible, but typically in a grayed out or inactive state so that it doesn't allow interaction with the user other than visually".

[Ed Minchau]

If you're doing bit operations,  I assume that section is in asm? The BBR/BBS commands come in very handy for this.

Edited to add: I'm doing something like that for the row of buttons near the top of the screen in Asteroid Commander. Each one is a 4bpp sprite, and has a flag bit in a zero page byte called BUTS.

The routine that draws these sprites uses the BBR commands to check the associated bit. Whether it's a 0 or 1 determines which palette offset is chosen for the sprite attribute. Similarly the subroutine that checks for mouse position won't recognize a button that has a zero flag.

I've had to set aside an additional 3 bytes of zero page for flag bits on buttons in the message window, only a few of which can be active at one time.

[BruceMcF]

if you would need both, it's really just a naming question, whether to name the force_draw function "draw_widget" or the visiible_draw function "draw widget". I would lean toward the first: have the base action to just draw the widget, and the alternative function be visible_draw.

[rje]

In your library, what the heck is a widget?  Is this another word for sprite?

[Scott Robison]

5 minutes ago, rje said:

In your library, what the heck is a widget?  Is this another word for sprite?

A widget is a generic term for a user interface control (among other uses): https://en.wikipedia.org/wiki/Graphical_widget

[rje]

Ah, right!  you know, I guess I just never expected to see that term in the x16 context.

[ZeroByte]

16 hours ago, Ed Minchau said:

If you're doing bit operations,  I assume that section is in asm? The BBR/BBS commands come in very handy for this.

I've forgotten about those 65c02 instructions and recall that they definitely looked quite useful. For now, it's almost entirely written in C, but I am organizing the project such that each and every function is in its own .c file

This is to give the linker the ability to only link in code that is actually used, as ld65 links in code in units of .o files - i.e. if you have a .o file with 5 functions, but your project only uses one of the 5, you're still getting all 5 functions' code in your executable. But this also means that it should be easier to go back and convert any particular routine into pure assembly w/o affecting the project as a whole.

In general, when optimizing code, you end up having to prefer speed or size as your optimization target. For now, I'm choosing size because I want the engine to leave as much of the base resources available as possible for the using code's benefit. Thus all widgets and click boxes are being stored in RAM banks. I'll probably sacrifice a couple of pages' worth of the widgets' struct bank for a list of widgets that want global signals in order to speed up the global signal processing phased of the update_widgets() function.

I do have one "hello world" program working which has a single widget that scrolls text through a small 8-char "window". Its updates are triggered by the global timer.