[scripts api manual] updated dtutils.file/check_if_bin_exists to document
the updated functionality. Added dtutils.file/test_file to document new function for file testing. [scripts manual] Updated script_manager to document rewrite of script.
This commit is contained in:
parent
500ae67bf3
commit
e76a08f7dd
3 changed files with 98 additions and 18 deletions
|
@ -24,12 +24,32 @@ local result = df.check_if_bin_exists(bin)
|
||||||
## DESCRIPTION
|
## DESCRIPTION
|
||||||
|
|
||||||
**check_if_bin_exists** checks to see if the specified binary exists.
|
**check_if_bin_exists** checks to see if the specified binary exists.
|
||||||
**check_if_bin_exists** first checks to see if a preference for the binary has been
|
**check_if_bin_exists** looks for an executable in the following order:
|
||||||
registered and uses that if found. The presence of the file is verified, then
|
|
||||||
quoted and returned. If no preference is specified and the operating system is
|
* If an executable preference is registered, then it's checked to make sure it's a file, exists, and is executable. If it passes all these tests it is returned to the caller. On non-windows operating systems a windows binary can be specified and the wine installation will be checked for the executable.
|
||||||
linux then the which command is used to check for a binary in the path. If found
|
|
||||||
that path is returned. If no binary is found, false is returned.
|
* If an executable preference doesn't exist or a test fails then an attempt is made to find the file in an operating system specific manner:
|
||||||
|
* unix or linux
|
||||||
|
* the user's path is checked for a matching binrary using the which command
|
||||||
|
* macos
|
||||||
|
* first the user's path is checked for a matching binrary using the which command
|
||||||
|
* if the executable isn't found a search of the _/Applications_ directory is performed
|
||||||
|
* windows
|
||||||
|
* the user's path is checked using the where command
|
||||||
|
* if the executable isn't found, then _C:\\Program Files_ is searched for the executable
|
||||||
|
* if the executable isn't found, then _C:\\Program Files \(x86\)_ is searched
|
||||||
|
|
||||||
## RETURN VALUE
|
## RETURN VALUE
|
||||||
|
|
||||||
**result** - _string_ - the sanitized path of the binary, false if not found
|
**result** - _string_ - the sanitized path of the binary, false if not found
|
||||||
|
|
||||||
|
## LIMITATIONS
|
||||||
|
|
||||||
|
* it still can't find GIMP on windows. GIMP on windows is installed in C:\\Program Files\\GIMP 2\\bin\\gimp-2.10.exe, if you use the installer from www.gimp.org. When **check_if_bin_exists** searches for GIMP it looks for gimp.exe. If the search was for gimp\*exe then things like gimptool, gimp-debug-tool, gimp-console, etc. are found. Depending on who packaged gimp,there is an executable called gimp.exe which satisfies the search but is a GIMP launcher that exits immediately so the script returns and the image is not edited. Therefore, if you are a windows user, then you need to specify the location of the GIMP executable either from the [Edit with GIMP](../../../lua.scripts.manual/scripts/contrib/gimp.md) script or using [executable manager](../../../lua.scripts.manual/scripts/tools/executable_manager.md).
|
||||||
|
|
||||||
|
* flickering windows - on windows every command must run in a window, so every time a script uses a system command a window is opened, the command is run, and the window is closed checking for a binary needs multiple system commands to find the file and then check it which causes "flickering windows". If the flickering windows is too disturbing a lua preference is available in the settings to use the old check_if_bin_exists\(\). The old check_if_bin_exists\(\) still causes flickering windows but it's much less. The downside is that no searching is performed so the user has to specify the location of all executables.
|
||||||
|
|
||||||
|
|
||||||
|
## CHANGELOG
|
||||||
|
|
||||||
|
20201225 - Added search capability and file checking to ensure it's an executable - Merry Christmas
|
||||||
|
|
35
content/lua.scripts.api.manual/dtutils.file/test_file.md
Normal file
35
content/lua.scripts.api.manual/dtutils.file/test_file.md
Normal file
|
@ -0,0 +1,35 @@
|
||||||
|
---
|
||||||
|
title: test_file
|
||||||
|
id: test_file
|
||||||
|
weight: 200
|
||||||
|
draft: false
|
||||||
|
author: "people"
|
||||||
|
---
|
||||||
|
|
||||||
|
## NAME
|
||||||
|
|
||||||
|
test_file
|
||||||
|
|
||||||
|
## SYNOPSIS
|
||||||
|
|
||||||
|
test a file to see what it is
|
||||||
|
|
||||||
|
## USAGE
|
||||||
|
```
|
||||||
|
local df = require "lib/dtutils.file"
|
||||||
|
local result = df.test_file(path, test)
|
||||||
|
```
|
||||||
|
**path** - _string_ - path and filename
|
||||||
|
**test** - _char_ - one of d, e, f, x where
|
||||||
|
* d - directory
|
||||||
|
* e - exists
|
||||||
|
* f - file
|
||||||
|
* x - executable
|
||||||
|
|
||||||
|
## DESCRIPTION
|
||||||
|
|
||||||
|
**test_file** checks a specified path to see if it meets the specified test
|
||||||
|
|
||||||
|
## RETURN VALUE
|
||||||
|
|
||||||
|
**result** - _boolean_ - true if the path satisfies the test, false if not
|
|
@ -12,33 +12,58 @@ script_manager.lua - a tool for managing the darktable lua scripts
|
||||||
|
|
||||||
## Description
|
## Description
|
||||||
|
|
||||||
script_manager is designed to run as a standalone script so that it
|
script_manager is designed to be called from the users luarc file and used to manage the lua scripts.
|
||||||
may be used as a drop in luarc file in the user's $HOME/.config/darktable
|
|
||||||
($HOME/AppData/Local/darktable on windows) directory. It may also be
|
|
||||||
required from a luarc file.
|
|
||||||
|
|
||||||
On startup script_manager checks to see if there is an existing scripts directory.
|
On startup script_manager scans the lua scripts directory to see what scripts are present.
|
||||||
If there is an existing lua scripts directory then it is read to see what scripts are present.
|
Scripts are sorted by 'category' based on what sub-directory they are in. With no
|
||||||
Scripts are sorted by "category" based on what subdirectory they are found in, thus with a lua
|
additional script repositories iinstalled, the categories are contrib, examples, official
|
||||||
scripts directory that matched the current repository the categories would be contrib, examples,
|
and tools. When a category is selected the buttons show the script name and whether the
|
||||||
offical, and tools. Each script has an Enable/Disable button to enable or disable the script.
|
script is started or stopped. The button is a toggle, so if the script is stopped click
|
||||||
|
the button to start it and vice versa.
|
||||||
|
|
||||||
A link is created to the user's Downloads directory on linux, unix and MacOS. Windows users must create the
|
## Features
|
||||||
link manually using mklink.exe. Additional "un-official" scripts may be downloaded
|
|
||||||
from other sources and placed in the users Downloads directory. These scripts all fall in a downloads category.
|
|
||||||
They also each have an Enable/Disable button.
|
|
||||||
|
|
||||||
|
* the number of script buttons shown can be changed to any number between 5 and 20. The default is 10 buttons. This can be changed in the configuration action.
|
||||||
|
|
||||||
|
* additional repositories of scripts may be installed from the install/update action.
|
||||||
|
|
||||||
|
* installed scripts can be updated from the install/update action. This includes extra repositories that have been installed.
|
||||||
|
|
||||||
|
* the lua scripts can be disabled if desired from the install/update action.
|
||||||
|
|
||||||
|
* script_manager is automatically installed and enabled when the lua scripts are installed by the darktable scripts_installer.
|
||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
|
|
||||||
|
* start/stop scripts -
|
||||||
|
* The top part of the window has the **category selector**. The category corresponds to the directory that the scripts are in. Currently the categories are _contrib_ for community contributed scripts, _examples_ for example scripts, _official_ for developer contributed scripts,
|
||||||
|
and _tools_ containing tools for managing the lua scripts.
|
||||||
|
* The lower part of the window contains the paged interface for the scripts contained in the selected category. There are arrow buttons for navigating the pages and an indicator showing what the current page is and how many pages of scripts there are for the current category. The number of buttons defaults to 10, but is configurable anywhere between 5 and 20 depending on how much screen real estate you want to use. The scripts are sorted alphabetically. The button shows the name of the script and it's current status, started or stopped. Clicking the script button toggles the script from started to stopped and back again.
|
||||||
|
|
||||||
|
* configure - this window allows changing the number of buttons used to display scripts. Move the slider to select the number of buttons, click the _change number of buttons_ button and the number of buttons will change and the action will change back to the start/stop scripts window.
|
||||||
|
|
||||||
|
* install/update scripts - This window allows installing additional script repositories and updating installed repositories.
|
||||||
|
* update - select the scripts to update from the _scripts to update_ dropdown. Click the _update scripts_ button to do the update.
|
||||||
|
* install - additional script repositories can be added to your lua scripts. To add another repository fill in the _URL to download additional scripts from_ and then fill in the _new category to place scripts in_. Click the _install additional scripts_ button and the category \(directory\) is created and a git clone is performed to retrieve the git repository. EXAMPLE: fill in _URL to download additional scripts from_ with https://github.com/wpferguson/extra-dt-lua-scripts.git and the _new category to place scripts in_ with wpferguson. Click the button to install the scripts. The scripts are retrieved and added to the user interface and the window changes to the newly installed script category.
|
||||||
|
|
||||||
|
* disable scripts - the lua scripts are installed by the darktable scripts installer. If you install them and later decide you no longer want them cluttering up your user interface, this option can disable them and stop them from starting. Once they are disabled, the way to enable them again is to rename a file using the terminal and command line. To disable the scritps first click the checkbox to enable the _Disable Scripts_ button. This is to prevent accidentally disabling the lua scripts. Once the _Disable Scripts_ button is active, click it to disable the scripts. When the button is clicked, the luarc file is renamed to luarc.disabled which results in the scripts not starting the next time darktable starts.
|
||||||
|
|
||||||
|
|
||||||
## Additional Software Required
|
## Additional Software Required
|
||||||
|
|
||||||
|
git - wwww.git.org - git is used to install and update the scripts. script_manager will still run if git is not installed or accessible, but installing and updating scripts will not be possible.
|
||||||
|
|
||||||
|
|
||||||
## Limitations
|
## Limitations
|
||||||
|
|
||||||
|
* There isn't currently a way to stop an executing script and remove it from the interface, so when a script is stopped the script preference is set to not start the next time darktable starts.
|
||||||
|
|
||||||
|
* If the scripts are disabled by choice the only way to enable them is by renaming the file luarc.disabled to luarc. Then file is located in the user's darktable configuration directory, $HOME/.config/darktable on linux and macos and %LOCALAPPDATA%\\darktable on windows.
|
||||||
|
|
||||||
## Author
|
## Author
|
||||||
|
|
||||||
|
Bill Ferguson \<wpferguson@gmail.com\>
|
||||||
|
|
||||||
## Change Log
|
## Change Log
|
||||||
|
|
||||||
|
20201225 - Rewrite for darktable 3.4 - Merry Christmas
|
Loading…
Reference in a new issue