Why strings as input parameters

[cupsster]

Hi, why did you chose to use strings as input parameters to functions? Is there any practical reason to do so? Why not expose API directly and use parameters instead.
I like the library but I'm scratching my head how to plug this to my codebase. Also is there possibility to have multiple "Terminal" classes at once? Eg I'm trying to make rougelike and I would welcome to have screen split to regions, terminals if you like. One for main map draw, one for minimap and one or more to draw stats and UI.
Also I'm having very hard time to run CMake (I'm using gui version 3.10.0) and I constantly get this error message when trying to configure project:

CMake Error at Terminal/CMakeLists.txt:102 (install):
  install Library TARGETS given no DESTINATION!


Configuring incomplete, errors occurred!
See also "C:/_CP_Dev/Libraries/bearlibterminal/Build/CMakeFiles/CMakeOutput.log".

[cfyzium]

Sorry, missed the notification about this issue.

why did you chose to use strings as input parameters to functions?

I assume you're talking about terminal_set function?

There were a few overlapping reasons and factors that have led to heavily 'stringly-typed' configuration. A core part of configuration, fonts and tilesets specification, is rather complex and not easy to implement in form of a function or two. There are a lot of parameters, common and type-specific, optional, mutually exclusive, some weakly-typed (e. g. may be either value or 'auto'), etc. It might have been easier in Python but not in C, especially when it had to be the easiest C invokable from many other programming languages. Furthermore, parameters were being frequently added or adjusted during early stages of development. And then attempt to make bindings for a lot of languages complicated the process further. Not only parameters, every additional API function increased the amount of maintenance.

String based configuration became a solution to several problems at once. It may not be an ideal solution but it have served its purpose well.

One of the reasons it shouldn't have been a big issue is that usually most of the configuration is set once during startup and the terminal_set function is not called frequently. However, things may change soon...

I would welcome to have screen split to regions, terminals if you like. One for main map draw, one for minimap and one or more to draw stats and UI

...because after window backend refactoring (that SDL stuff, though it looks like it won't be only SDL) it will be the turn of those very sub-terminals, or 'panels'. A huge and important feature that most likely will require significant changes to API because unlike the global 'main' terminal, panels are likely to be modified frequently.

It would be too clunky to modify size and position, relative placement and other properties thought the function(s) similar to terminal_set. I do not know how will it end up exactly but at least some of the properties and settings will naturally get their own setters and getters.

Ideally, the entire configuration will be refactored into functions, I do understand that strings is but a compromise.

As an interim measure I suggest making lightweight wrappers like this:

bool terminal_set_size(int width, int height)
{
    return terminal_setf("terminal.size=%dx%d", width, height);
}

I constantly get this error message when trying to configure project

Are you using the latest code? Because this particular issue should have been resolved a few months ago.