Is there a way to initiate HDR/panorama or focus merge from the command line?

[v_kyr]

2 minutes ago, R C-R said:

What makes you think there is any support at all for CLI commands or for handling flags or arguments (appropriate or not) built into the Affinity apps? All I am hearing is that you have programmed apps to support those things, but it still sounds like you are just guessing about the presence of anything remotely like that in the Affinity ones.

Where ever did I said that there is already such support? What I said instead is that it is trivial to do or add this. - Further it's obvious you don't have any clues about programming or the like and you doubt what a software engineer with xx years of experiences and specialisation in OO modeling and development techniques is trying to explain you here.

I'm by far not guessing here, I know how common C++/ObjC apps and the like are programmed, how their app entry points look like and what you can pass over there from cmd args when wished. Something you seem not to have any idea off and thus you might think there is some magic around those things.

Quote

On the contrary, it is something any viable interface must deal with! No interface can access something that isn't there & it must not leave anything in an undefined or unstable state, regardless of what it can or can't access. This is just as important for a CLI as for a scripting API.

That's pretty much the base, where NIX is you also can't access NIX. - I mean it's logical and every serious developer is no idiot who doesn't care about such things. Of course you check and test in the code for such things, if objects are NIL and if certain pre- and post conditions are met etc. That's all common usage and nothing special when developing code.

[hlkhllhhhh]

3 hours ago, R C-R said:

What makes you think there is any support at all for CLI commands or for handling flags or arguments (appropriate or not) built into the Affinity apps? All I am hearing is that you have programmed apps to support those things, but it still sounds like you are just guessing about the presence of anything remotely like that in the Affinity ones.

 

This is not about anything as vaguely defined as identifying "design patterns." It is about what actually exists in the code & how it could be accessed from the command line. Have you searched through the code & found anything that even suggests it includes any command strings, perhaps in some encoded or tokenized form, or a command line interpreter, or anything else you would expect to find in an app that offered a CLI?

 

On the contrary, it is something any viable interface must deal with! No interface can access something that isn't there & it must not leave anything in an undefined or unstable state, regardless of what it can or can't access. This is just as important for a CLI as for a scripting API.

Do you actually write code for a living or what makes you making these statements?

[R C-R]

2 hours ago, v_kyr said:

What I said instead is that it is trivial to do or add this.

Actually, what you said was it would be trivial for certain "common things." Throughout this discussion you have made liberal use of qualifiers like "common," "some," or "mostly" & relied on the somewhat nebulous idea that "since the Affinity tools are frontend/backend oriented built up and also do use the common Win/MacOS programming APIs, they can add those things also on demand." All this while also maintaining you do not need to know anything about "those backends, etc." that activate a UI panel in Affinity.

 

At the least, do you see how this might be interpreted as a mixed message that might just be oversimplifying things a tad too much?

 

7 minutes ago, hlkhllhhhh said:

Do you actually write code for a living or what makes you making these statements?

As I said near the beginning of this discussion, my statements are based on what people who have been writing code for a living for decades tell me, which is considerably different in almost every respect from what you or v_kyr have been saying. I mean neither of you any disrespect but I know these people, who they have worked for, & what they have done. I don't know any of that about either of you, so I am far more inclined to take their word over yours.

[hlkhllhhhh]

3 minutes ago, R C-R said:

As I said near the beginning of this discussion, my statements are based on what people who have been writing code for a living for decades tell me, which is considerably different in almost every respect from what you or v_kyr have been saying. I mean neither of you any disrespect but I know these people, who they have worked for, & what they have done. I don't know any of that about either of you, so I am far more inclined to take their word over yours.

I would recommend that you either let these people do the talking for you directly or tone down your comments. You sound like someone who has heard a few things, repeats them, but has no real understanding or experience. Your comments about OOP or patterns already show confusion.

 

I don't want to offend you but you are making something straightforward into something complex and you are not helpful.

[v_kyr]

Quote

At the least, do you see how this might be interpreted as a mixed message that might just be oversimplifying things a tad too much?

How would you explain such things to a non coder/developer, if you don't know how his overall knowledge about software development skills, the internals of programming languages, OO/procedural/functional programming concepts, the common Win/Mac programming APIs for those things and all that etc. are?

I could also throw a bunch of code examples on you, which programmers usually understand by looking on the code without much additional explanatory words, but I know that this wouldn't be of much help for you. I also doubt that you really know anything about software design per se and just rely here on what some people may probably have told you or what you have heard of. - Believe me there is also quite a difference between heard in theory and practise and you can be sure, that I wouldn't bother my time here trying to explain you, if I wouldn't know what I'am talking about!

[R C-R]

11 minutes ago, hlkhllhhhh said:

I don't want to offend you but you are making something straightforward into something complex and you are not helpful.

If this is all so straightforward then why all the hedging with common this & mostly that? Or perhaps more to the point, why is it that so few apps provide any kind of CLI at all, & many if not most that do only provide it for certain well documented operations?

[hlkhllhhhh]

6 minutes ago, R C-R said:

If this is all so straightforward then why all the hedging with common this & mostly that? Or perhaps more to the point, why is it that so few apps provide any kind of CLI at all, & many if not most that do only provide it for certain well documented operations?

I am giving up.

 

Is Affinity actually reading this forum and do they comment?

[R C-R]

1 minute ago, hlkhllhhhh said:

Is Affinity actually reading this forum and do they comment?

Yes they do, but as has been mentioned in several topics most of the staff are off for the holidays & will return to work in the new year.

[v_kyr]

19 minutes ago, R C-R said:

...Or perhaps more to the point, why is it that so few apps provide any kind of CLI at all, & many if not most that do only provide it for certain well documented operations?

What apps are you talking about and also what is your understanding of being a CLI for those then?

If you mean graphics apps look as an more feature rich example at the Gimp batch mode here.

[R C-R]

11 minutes ago, v_kyr said:

What apps are you talking about and also what is your understanding of {there} being a CLI for those then?

With a few exceptions, just about every commercial app I have bought & use on my Mac, whether a graphics oriented app or not. What I mean by that is they neither provide nor document anything remotely like a public API that provides access to commands usable in a CLI environment like say Apple's Terminal.app. I am not talking about API's provided by the Mac OS (some of which are public & well documented but many are private & explicitly reserved for the exclusive use by Apple), but those provided by the apps themselves.

 

I am not sure what you are suggesting but I hope it is not that I should try to guess what commands an app might support without at least some minimal form of documentation to guide me.

[v_kyr]

Well it depends on the sort of app, it's intentional use and also what then makes possibly sense for such an app to support.

On a Mac they handle things often slightly differently here, also sometimes due to the things which initially have been taken over from the former NeXTstep/OpenStep times once. For example let's take a look at the systems TextEdit app, which you invoke instead via the open

• "open -e filename"

command or by specifying the app explicitely via

• "open -a TextEdit filename"

instead. If TextEdit is not setup as your default editor,

• "open -t filename"

will for example instead open the passed file inside your default associated text editor. In order to show up any longer console/terminal output you can also pipe the output of a terminal command to be opened into the default editor.

• "ls | open -f"

One bad thing about TextEdit is that it doesn't support to show up line numbers inside, but with this here

• "awk '{print FNR "\t" $0}' ~/Desktop/myfile.txt | open -f"

you can force it to place some line numbers in front of a shown text file lines. BTW other editors like for example SublimeText etc. do offer more useful cmdline args usage here.

The bad think on Apple Mac systems is that they tend to hide the overall power of the underlayed Unix system tools which are all also available as command line tools. They even don't document obviously many available and possible things here, maybe since they continue to sell the marketing illusion, that the Apple MacOS system is still being a pretty user friendly and easy to handle GUI related OS (hiding it's Unix roots). BTW the same was done at NeXT in the past, there we always only were allowed to show how cool things work the GUI way and not what was used underneath the GUI frontends.

[v_kyr]

Forgotten to mention that of course the following on OSX works too:

open -a "Affinity Designer"
open -a "Affinity Designer" filename.afdesign
open -a "Affinity Designer" filename.png
open -a "Affinity Designer" filename1.png filename2.png
...etc...

 

see also the open manpage for further open cmd related options!

[R C-R]

FWIW, I am familiar with using open & most of the other common commands that have regularly appeared in Mac-oriented 'tips & tricks' articles beginning not long after the first version of OS X was released, & even with a few of the more obscure ones. That is not as unusual as you might think -- Apple used to tout Terminal.app with flowery marketing hype about 'harnessing the power of UNIX,' made a big deal of its drag & drop capability, & such. It does not do that much these days but there are still lots of Mac users who use Terminal regularly & you can still find Apple support articles that suggest using Terminal to solve tricky problems that would be difficult or impossible to solve with the GUI.

 

But as I am sure you know, it is not the app itself but the OS that is providing the functionality of the open command, passing file name arguments to the app, relying on LaunchServices to determine the default app if none is provided, locating files when no explicit file path is specified, & so on. Accessing the functionality of the app itself is an entirely different thing.

[v_kyr]

Apple? - Pah, that "open" cmd tool stems from good old NeXT times as most other OSX things too.

There under NS there was also another "open" aka "Open Files with Applications" tool available, AFAI remember we used mostly that one from Ken Turner (the author who wrote this one). His open tool was initially implemented as a smaller bourne shell script and of course was intended to be run therefor from Terminal.app, another NS one just having been taking over by Apple later.

#!/bin/sh
#
# "open"	K. J. Turner	13/12/95
#
# This script starts applications for the files given as parameters.
# If a file extension is not given, a file with an extension is used
# if it is unique. If the file extension is not unique, the first one
# alphabetically is proposed. Extensions ending with "~" or ".backup" are
# assumed to be backup files and are ignored. Similarly, files with a ".lck"
# extension are taken as lock files and ignored.

# The script takes the same "-a" (application) and "-p" (print) flags as the
# usual "open" command. The directory for this script must appear ahead of
# the directory for the standard "open" (i.e. "/usr/bin/open") in $PATH.

flags=""
files=""
prog=`basename $0`

trap 'echo; echo $prog: abandoned; echo; exit 1' 2 3 15

if [ $# -eq 0 ]
  then
    echo "usage: $prog [-a app] [-p] files"
    exit 0
fi

while [ $# -gt 0 ]
  do
    case $1 in
      -a)
        flags="$flags -a $2"; shift 2;;
      -a*)
        flags="$flags -a `expr $1 : '-a\(.*\)'`"; shift;;
      -p)
        flags="$flags -p"; shift;;
      -*)
        echo "$prog: unknown flag $1"; shift;;
      *)
        file="`basename $1`"		# strip off leading directories
        file=`expr "Z$file" : 'Z\(.*\)\..*'`
	if [ "$file" = "" ]
	  then				# filename has no dot
	    names=""
	    count=0
	    for name in $1 $1.*		# consider all extensions
	      do
	        if [ "$name" != "$1.*" -a -r "$name" ]
		  then
		    ext="`expr Z$name : 'Z.*\(~\)'`"
		    if [ "$ext" = "" ]
		      then ext="`expr Z$name : 'Z.*\.\([^.]*\)'`"
		    fi
		    if [ "$ext" != "backup" -a "$ext" != "lck" \
		         -a "$ext" != "~" ]
		      then		# ignore backup and lock files
			names="$names $name"
			count=`expr $count + 1`
		    fi
		fi
	      done
	    if [ $count -eq 1 ]
	      then
	        files="$files $names"
              else
	        if [ $count -gt 1 ]
		  then
		    for name in $names
		      do
			echo -n "$prog: ambiguous name, use $name (y/n)? "
			read ans
			if [ "$ans" != "n" -a "$ans" != "N" ]
			  then
			    files="$files $name"
			    shift
			    continue 2
			fi
		      done
		fi
	    fi
	    shift
	  else				# filename has dot
	    name="$1"
	    ext="`expr Z$name : 'Z.*\.\([^.]*[^~]\)$'`"
	    if [ "$ext" = "" ]		# extension ends with ~, so set this
	      then ext="~"
	    fi
	    if [ "$ext" != "backup" -a "$ext" != "lck" -a "$ext" != "~" ]
	      then			# ignore backup and lock files
		files="$files $name"
	    fi
	    shift
	fi;;
    esac
  done

if [ "$files" != "" ]
  then /usr/bin/open $flags $files
  else echo "$prog: no files to open!"
fi

exit 0

The binary version of the open cmd tool is historically pretty old, first time I think I've used that one around 1992 together with TextEdit.app and InterfaceBuilder etc. for NS ObjC and C/C++ programming. - So that's all well known old stuff usually no Apple user needs to tell me about, since I already used all that intensively in former times, so to say long time before nowadays Apple users had any clues about those things at all. - However sometimes it's sad to see how time goes by and also to see how people often forget (me too here) where some things initially really do come from!

Back to topic, an application itself has of course to be able to handle those parameters and files given as arguments, or at least the ability to read from stdin/stdout here, otherwise it wouldn't do anything reasonable here. Most Unix OS command line programs and shell scripts are intended to work this way, meaning they support stdin/stdout, some passed over control flags and file arguments etc. Thus you can pipe the output from one unix system prog as input to another one and so on, pretty much the good old K&R Unix working concept of how to chain and work with standard small Unix utility programs. - For GUI applications you can offer and implement the same command line handling capabilities here, so they can also be invoked with certain defined and given arguments then just from a shell/terminal instead of the GUI desktop.