You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current mechanism uses a control file for static info and a control.pl for requesting more information to complete the template. This format works for the command line but it would be complex to implement if we wanted to allow graphical interfaces to interact with NIC to generate projects from these templating system.
In this issue I'd like to propose a significant architectural change that would allow integration with both command line and graphical interfaces alike while slightly expanding the versatility of the NIC templating system.
Example of current architecture (NIC v2):
NIC/control
name "iphone/tweak"
prompt FILTER "MobileSubstrate Bundle filter" "com.apple.springboard"
constrain file "control" to package
constrain "theos" to link_theos
NIC/control.pl
my$default_kill = "SpringBoard";
NIC->variable("KILL_PROCS") = "";
my$kill_apps = NIC->prompt("KILL_APPS", "List of applications to terminate upon installation (space-separated, '-' for none)", {default=>$default_kill});
if($kill_appsne"-") {
NIC->variable("KILL_PROCS") = "INSTALL_TARGET_PROCESSES = ".$kill_apps."\n";
}
Instead I'd like to propose a YAML file
NIC/control.yml
---
name: tweakplatforms:
- iphoneconstraints:
control: packagetheos: link_theosvariables:
- FILTER:
prompt: "MobileSubstrate Bundle filter"default: com.apple.springboard
- KILL_PROCS:
prompt: "List of applications to terminate upon installation (space-separated, '-' for none)"default: SpringBoardcancel: -format: "INSTALL_TARGET_PROCESSES = {}"
Under this model, the name from the current model is split into platforms and name, allowing simple filtering. In cases where a template, like the tool one, supports multiple platforms, the user can choose which one to generate for.
Documenting NIC should come first so we can identify the internal/builtin variables and constraints and how they work, plus functionality like ignored variables.
This is by no means the final draft and I'm open to discussions.
The text was updated successfully, but these errors were encountered:
The current mechanism uses a
control
file for static info and acontrol.pl
for requesting more information to complete the template. This format works for the command line but it would be complex to implement if we wanted to allow graphical interfaces to interact with NIC to generate projects from these templating system.In this issue I'd like to propose a significant architectural change that would allow integration with both command line and graphical interfaces alike while slightly expanding the versatility of the NIC templating system.
Example of current architecture (NIC v2):
NIC/control
NIC/control.pl
Instead I'd like to propose a YAML file
NIC/control.yml
Under this model, the name from the current model is split into
platforms
andname
, allowing simple filtering. In cases where a template, like the tool one, supports multiple platforms, the user can choose which one to generate for.Documenting NIC should come first so we can identify the internal/builtin variables and constraints and how they work, plus functionality like ignored variables.
This is by no means the final draft and I'm open to discussions.
The text was updated successfully, but these errors were encountered: