Hi @VertigoRay

Few comments:

• screenBuffer instances got a .fill() method, no need to use .put() with an array to init them
• terminal instances and screenBuffer.put() already got printf-like behavior, you don't need an sprintf module at all.
  E.g.: screenBuffer.put( options, 'CPU Cores: %d | Free Memory: %s' , os.cpus().length , os.freemem())
• screenBuffer are already init with space characters
• your account() function actually draws the same things in all screenBuffer: the gray background color, that's why you can't see anything, I'm not sure what you are trying to do there

from terminal-kit.

I'm trying to make something like a <table> (html). It won't necessarily have a header row, but I can fill in the grid with data. Some of the cells will be labels, others will be data. That account area will show account information. I'll make several other sections to show status of others, but they're all generally shaped the same.

The end goal for that account section is to have something like this:

Obviously, the empty cells, don't need to be cells ... I'm just trying to structure it well so you can get a visual. It doesn't even have to be cells; that's just the way my brain is organizing it right now.

Ideally, I can just call the account() function, passing a data parameter (doesn't exist yet), and it'll fill in the %Variables%.

The interface will just show data output for now. I don't plan to have any inputs or menus or anything. I have a config file for that. Maybe someday, I can add that into the interface, but it's definitely not going to be part of v1.

I remember trying to fill() and getting weird artifacts. I'll look at the documentation again to make sure I was doing it correctly.

One of the reasons I used sprintf is to have a complete string so I can get the length of it and calculate the center justification of the text. Unless you have an undocumented center keyword for x, y, width, and/or height.

I already built this in electron, but now I want to run it on a headless server. I thought having the output display in a similar fashion would work well, and I could just leave it running in screen. Anyway, I think that explains what I'm trying to do a little better. Thoughts?

from terminal-kit.

I definitely wasn't doing the fill() correctly. I have that working now.

from terminal-kit.

Maybe I'm just doing the nested ScreenBuffers wrong, but it's still not working:

The label, "Account", it's showing up in the top left of the box:

I did confirm that I can fill in coordinates and just redraw the main account box. Should I just do that, or do you happen to have a better way?

New account() Code

function account () {
	// let info = sprintf('CPU Cores: %d   |   Free Memory: %s', os.cpus().length, os.freemem());
	// let c_justify = Math.ceil((term.width / 2) - (info.length / 2));
	let options = {
		x: 0,
		y: 0,
		wrap: false,
		attr: {
			color: 'black',
			bgColor: 'green',
		},
	};


	let label = 'Account'
	let b_account_label = tkit.ScreenBuffer.create({
		dst: b_account,
		x: 1,
		y: 3,
		width: label.length,
		height: 1,
		// blending: true,
		// noFill: true,
	});

	b_account_label.put(options, label);
	b_account_label.draw();

	options.y = 2;
	b_account.put(options, 'b_account width: %d; height: %d', b_account.width, b_account.height);
	b_account.draw();
}

from terminal-kit.

@VertigoRay Depending on the level of complexity of your application, it may be overkill to use nested screenBuffers, and might even be overkill to use screenBuffers at all.

Are those cells static? dynamic? contains user input? Is the app redraw-intensive?

• For static cells or if the redraw rate is low, without user interaction, I would avoid screenBuffers, since they are a bit too low-level
• For dynamic cells with intensive redraws, I could go either way, but wouldn't nest
• If there are a lot of user input widgets, I would use the document model, but unfortunately this is still an undocumented alpha feature. You can have a look of the document model capabilities in sample code, into the sample/document/ folder, to see if it fits your need. It can manage a lot of things for you: which widget has input focus, focus cycling, and so on. You can use if you lock your terminal-kit dependency to 1.11.x. Even if the document model is not under the semver contract (not documented), I never publish a patch-level upgrade that contains non-bugfixes.

Nested screenBuffers are trivial to understand:

• first draw the nested screenBuffers to the master screenBuffer
• then draw the master screenBuffer to the terminal
• nested screenBuffer coordinates are relative to the master screenBuffer

from terminal-kit.

Seems to be going in a favorable direction now. Thanks so much for your guidance.

from terminal-kit.