weixin_39696518
2020-12-09 09:48 阅读 1

Please add more variables for Actions

It seems that currently only %f for file path is available for actions. It would be useful to also provide %x, %y, %w, %h for geometry of current selection (or if no selection, %x, %y would be image's pixel location at current mouse pointer). This can be used, for example, with ImageMagick convert command. Note: This info is already shown in status bar, but is not "scriptable".

该提问来源于开源项目:wjaguar/mtPaint

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

9条回答 默认 最新

  • weixin_39658716 weixin_39658716 2020-12-09 09:48

    The question is twofold. First, what values need be exported as variables, what to name the variables, and how to represent those (if any such are needed) that are non-numeric, like the "indexed/RGB" state. As you're proposing the feature, you're tasked with inventing the names. :)

    Second, at the moment mtPaint treats only the "%f" sequence differently, leaving all the other "%" signs in place (including not reducing "%%" to "%"); in theory, someone's custom actions could break if some "%whatever" matches what is used for other purpose (some commandline utilities do take format strings for something or other). So, this'll introduce a slight backward incompatibility.

    点赞 评论 复制链接分享
  • weixin_39696518 weixin_39696518 2020-12-09 09:48

    I really only want %x, %y, %w, %h for selection's x, y, width, height; %X, %Y for pointer's x, y; %W, %H for image's width, height, which are all numeric. With this, mtPaint can be a lightweight GUI for region selection in images.

    For compatibility, you may add an option in Preferences to enable/disable extra variables substitution. If disabled (default), only %f is recognized. Or just add a menu item "Copy Geometry (to Clipboard)" in Selection menu. Or both!

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-09 09:48

    As to compatibility, there is a third option. mtPaint allows to begin a file action with a group of "conversion statements" like this: ">rgb>png gimp %f" means "save image as RGB PNG file and feed that to GIMP". http://mtpaint.sourceforge.net/handbook/en_GB/chap_A.html#SEC7 I can add a ">%" statement which would enable the extra substitutions: ">% echo %X %Y"

    As to copying geometry to clipboard, there is the question of how to represent it there. I think the least inconvenient option is to use a format string like the above, to export what the user wants the way he wants it. As to where the string goes - there are two non-conflicting possibilities. One is a pref (but the question is, what to name it?), another is a parameter in script (defaulting to that pref), like this: -i/geom="%X %Y %W %H" As scripts can be bound to hotkeys, one then could, if needed, have a choice of several different export formats at once.

    As an extra possibility, in commandline script mode the same command could write its results to standard output, for further processing in the calling script. However, in that case, for completeness would be needed variables for other things, such as file format, indexed/RGB, palette size, transparent color, presence of alpha/selection/mask channels.

    点赞 评论 复制链接分享
  • weixin_39696518 weixin_39696518 2020-12-09 09:48

    By the way, variable names (in this new mode) should be "delimited" (i.e. %{var}), e.g. crop "%{w}x%{h}+%{x}+%{y}" "%{f}".

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-09 09:48

    What for, if none of them is a prefix of another? Matching is done by prefix (as in many other places), something like "%free" will happily match "%f" and transform into "file.pngree"; and if it should not, it can be "quoted" as "%%free", to transform into "%free".

    点赞 评论 复制链接分享
  • weixin_39696518 weixin_39696518 2020-12-09 09:48

    For forward compatibility. If in the future, you introduces a new variable %fr, what should %free mean? %{f}ree or %{fr}ee?

    I think variables should be like "shell variables" ($var, or ${var} if neccessary), so in my example, it can be: crop "%{w}x%h+%x+%y" "%f". But forcing variables to be delimited allows more flexible variable names (e.g. %{color-#rgb}) .

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-09 09:48

    From experience, there are extremely few things stupider under the sun than "forward compatibility"; any code written with it in mind, is invariably wasted. If one is a seer, should predict the stock market instead; if one isn't, no point playing pretend.

    Specifically in this case, 26 letters * 2 cases = 52 possible single-char variables. Which is 2+ times more than there are fields in image state, and those fields accumulated over 16+ years. The probability of them ever doubling is observationally equivalent to a big, fat zero. :)

    点赞 评论 复制链接分享
  • weixin_39696518 weixin_39696518 2020-12-09 09:48

    Well, in this case, it's not a prediction of unknown, I think. Using only single letters as variable names can lead to confusion. For example, if %h is for height, then you must use %H for hue, now what should be used for header? Anyway, this is just a suggestion, you may do whatever you like. Hope to see this feature implemented soon, thanks!

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-09 09:48

    Added to 3.49.20

    点赞 评论 复制链接分享

相关推荐