KUIML console

[Dewdman42]

Here's a question for you KUIML gurus... I wonder if it would possible or difficult to program some kind of KUIML based console... so that I could send various messages to the plugin interface instead of to a file...

It would probably necessarily also need a scroll bar (gasp).

[Blue Cat Audio]

You could probably do that using a custom canvas and program the whole thing by hand to get a full featured console. An alternative would simply be to use a single line text edit box with a "send" button and enter commands one by one.

[Dewdman42]

I meant output only. A place to send print messages instead of a file

[Dewdman42]

So just dipping my toes into KUIML for the first time now, please forgive me and correct me if I am thinking of anything stupid...

But perusing through the docs of KUIML it seems like maybe I co old use the TABLE element to build a multi-row table on the GUI...and then perhaps some kind of thing where when I update the bottom row of the table, all the other rows shift up...essentially emulating a console output.

One thing I learned while reading through the KUIML docs is that I can associate script functions with certain kinds of KUIML events, which I guess is a good way to run some angelscript outside of the processBlock function.

So Basically I would use my own print function...which would buffer the lines...and then periodically something from KUIML would cause a different callback function which flushes the buffer to the KUIML table... something like that..

Am I on the right track?

[Blue Cat Audio]

That's indeed a possible way, but it might be even easier to simply generate a custom KUIML widget with TEXT elements in a column. To generate content dynamically from a script, you can use the KUIML_WIDGET element.

[Dewdman42]

when you say "generate a custom KUIML widget", I'm not sure what you mean exactly. But I will look into the KUML_WIDGET link you mentioned... thanks!

[Blue Cat Audio]

KUIML widgets are dynamic widgets which content you can generate after they have been created (like a skin loader inside the skin). That's the most powerful way to generate a GUI after the skin has been loaded. So it might help if you want to do complex things at runtime.

[ilyaorlov]

scroll_text.gif

There's an experimental extension to LM_Skin with "LOG" element that was done exactly for that purpose. It is in plans to rewrite it someday properly and then make public. You can try it already, though future updates of LM_SKIN may (and probably would) break backwards compatibility.

It's done via CANVAS and some tricks. You can use it like this:

Code: Select all

<LOG string_id="your_string_with_text" />

This string_id can be output_string from the DSP, so with some simple functions in the DSP you can make a function to print to log.

Here's a .kuiml example that should work in LM_Skin. You can ignore width="$RE100$" height="$RE100$" - these $RE100$ are set to 100% when skin is resizeable, otherwise empty.

Code: Select all

<?xml version="1.0" encoding="utf-8" ?>
<SKIN width="$RE100$" height="$RE100$">
	
	<INC file="$EXTENSIONS_DIR$log.inc" />

	<STRING id="text" default="The KUIML language lets you describe the structure of the user interface as well as its data model. It is a strongly typed, model-driven language. The purpose of the language is to be able to quickly write applications which, once loaded, produce as little runtime errors as possible.
\n\nKUIML is an XML dialect, with additional build-time capabilities implemented by Language Elements.
\nStarting with version 2.0, the data model can be accessed by scripts, in order to write more complex applications. Events have also been introduced to trigger several types of actions (including scripts), when the data model is modified, or when the user interacts with the application.
\nThe User Interface can be composed of Layout Elements to simplify layout design, and Widgets that are the actual building blocks of the interaction with the end user.
\n\nUser Interface Elements connect to the data model that can be either published by the application (see KUIML For Audio Plug-Ins for example) or described by Model Elements.
\nAll elements (including widgets and layout elements) may also expose attributes that become part of the data model and can be connected together.
\n\nAdditional Language Elements extend the core features of Xml to write KUIML user interfaces faster and improve code reuse.
\n\nKUIML offers specific concepts during loading/building phase (see Build Phases), such as TEMPLATE or VARIABLE which are not available anymore at runtime, when the application has been built and is running.
\n\nThese concepts will be referred to as &quot;built-time&quot; later in the manual, as opposed to the runtime model that describes the objects and concepts available to the application while running.
\n\nAll Language Elements are all &quot;built-time&quot;, whereas Model Elements and User Interface Elements are &quot;run-time&quot;.
" />
	
	<CELL min_width="450" width="$RE100$" height="$RE100$">
		<LOG string_id="text" height="$RE100$" background_opacity="0.4" show_edit_icon="0" />
	</CELL>


</SKIN>

[Dewdman42]

Thanks for that. I'm swamped this month but I will get back to this eventually...