#66 Provide "Open with ..."

SVN
closed
5
2013-05-21
2013-01-02
Ark
No

It would be nice if you could just right-click an image (or use the File menu) and choose an "Open with ..." submenu entry in order to open the image with any application you like. The entries of this submenu should be editable. I prefer the way emelFM2 does this: if you right-click a file and choose "Edit filetype.." you can specify both a label and a command line to run for every "Open with..." submenu entry.

This way, you could provide a workaround for the lack of support of animated GIFs: The user could just open it with "mplayer -loop 0 %f", for example.

And, of course, thank you for all the work you have done so far!

Discussion

1 2 > >> (Page 1 of 2)
  • Oddegamra

    Oddegamra - 2013-01-02

    Yeah, thinking about it, this is a pretty good idea. Since MComix doesn't open that many file types, having only a single list of commands for all file types might be enough.

    As for variables for command substitution, I'm thinking about something like this:
    %f - Absolute path to currently opened image (if the image was within an archive, this path points to the temporarily extracted file).
    %a - Absolute path to archive. If the file isn't in an archive, this might as well point to the containing directory.
    %d - Absolute path to directory of image/archive.

    Anything else that might be useful?

     
  • Ark

    Ark - 2013-01-02

    Thank you for your reply, oddegamra. I gave it a little more thought:

    The working directory should be the directory that contains the original file (i.e. image or archive).

    I suggest the following variables/sequences:

    "quotation marks" - for arguments containing spaces
    %" - the " character itself
    %/ - the path separator of the underlying OS, e.g. / on Linux and \ on Windows
    %% - the % character itself
    %f - name of the (extracted) image file
    %a - name of the archive file (raises an error if the file is not an archive)
    %D - absolute path to the directory containing the (extracted) image file
    %W - absolute path to the current working directory
    %w - name of the current working directory
    %F - absolute path to the (extracted) image file (same as %D%/%f or %D%f, depending on implementation [see below])
    %A - absolute path to the archive file (raises an error if the file is not an archive) (same as %W%/%a or %W%a, depending on implementation [see below])

    That is, lowercase variables refer to the name of a file or directory, uppercase variables refer to absolute paths.

    *Issues*

    This feature should work with files and arguments containing arbitrary Unicode characters.

    Another issue: Should paths to directories end with the path separator or not?
    Examples:
    - Should %W expand to C: or to C:\ on Windows machines?
    - Should %W expand to / or to the empty string on Linux machines?
    - Should %W expand to /home/me or to /home/me/ on Linux machines?

    Since there are some tools which treat /home/me and /home/me/ differently (rsync, for example), it should be that way: If the directory is a root directory (e.g. C:\ or /), %W should expand to C:\ or /, respectively. But if it is not a root directory, %W should expand to C:\me or /home/me, respectively. If you need to make sure that the argument ends with the path separator, you simply add a %/. Thus, %W%/ may expand to /home/me/ or // on Linux and C:\me\ or C:\\ on Windows, respectively. This seems to be okay on Linux, I hope the same is true for Windows.

    Another issue: Should %f expand to the single argument "my dog.jpg" or to the two arguments "my" and "dog.jpg"? I think "my dog.jpg" (single argument) would be a lot more convenient. Thus, %w.7z should expand to the single argument "my wallpapers.7z". "%w" and %w (without quotation marks) should both expand to "my wallpapers" (single argument).

    Some other features that belong to this feature request (more or less):

    - Optional keyboard shortcut for a command line (Since F8 is currently not in use, a simpler version would be a radio button to select one of these command lines at a time, indicating that this command line gets executed every time F8 is hit.)
    - Menu item "Copy filename to clipboard" (value of %f)
    - Menu item "Copy location to clipboard" (value of %D, same as File -> Properties -> Location)
    - Menu item "Copy archive path to clipboard" (value of %A, disabled if the file is not an archive)

    I hope my explanation was understandable. If you'd like, I could try and write a bit of Python code that transforms a command line to a list of arguments as described above. (Actually, I'm more used to Java, so beware of bad coding style.)

     
  • Ark

    Ark - 2013-01-03

    In my last comment I incorrectly called "/" and "\" path separators when I was actually talking about file separators. I'm sorry about that.

    I thought about the keyboard shortcut some more and now I think that exclusively assigning the F8 key (or another unused key) to the first command line would be easier to implement as opposed to selecting the desired command line through a radio button.

    I uploaded a file with a python script that performs the transform described in my last comment. There are some dummy variables left in the code because I don't know how to expand them appropriately in MComix. Furthermore, I don't know whether my coding style is okay and whether the code is fast/good enough. Hope it helps, though. (I'm not sure whether I used terms like "quotation" correctly, so feel free to correct them.)

    Some more issues:

    - Should environment variables be expanded after expanding MComix variables? However, this could become a problem (at least on Linux systems) if the name of an image file contains a dollar sign ($) because "$" signals the name of a variable.

    - Should an exception be raised if an invalid/incomplete escape or quotation sequence is detected or should they be left unchanged? I think syntax errors like "%x" should be reported as soon as they are entered in the preferences window, whereas using "%a" outside of an archive should not be reported before executing the corresponding command line. In any case, errors should always be reported and never suppressed/ignored.

     
  • Oddegamra

    Oddegamra - 2013-01-03

    >The working directory should be the directory that contains the original file (i.e. image or archive).
    So change working directory before executing a command, then.

    >This feature should work with files and arguments containing arbitrary Unicode characters.
    This shouldn't be a problem on Linux, and I hope that the subprocess module on Win32 uses the wide-character API when being passed Unicode strings from Python.

    >Another issue: Should paths to directories end with the path separator or not?
    Yeah, the user can add path separators himself if needed.

    >Another issue: Should %f expand to the single argument "my dog.jpg" or to the two arguments "my" and "dog.jpg"?
    The former. If a filename with spaces expands to multiple arguments, the resulting command will most likely be wrong unless the user is doing the quoting himself. Granted, he could. In any case, your script already handles this quite well.

    >In my last comment I incorrectly called "/" and "\" path separators when I was actually talking about file separators. I'm sorry about that.
    Well, it is called path separator in Python, so you're not wrong from my point of view.

    >Should environment variables be expanded after expanding MComix variables?
    Well, might as well, I guess? From what I can see, only valid environment variables are expanded by Python, and other names are left intact. So, unless someone has files like $HOME or $EDITOR hanging around, that shouldn't be much of an issue.

    After looking at your code a bit more, I thought about expanding environment variables before any MComix subsitution. That way, file names and such couldn't be affected. Unfortunately, expandvars on Windows replaces %% sequences with %, potentially ruining otherwise legal replacement strings. In any case, such a substitution might bring in invalid characters all by itself, e.g. $CMD="echo %asd%".

    >Should an exception be raised if an invalid/incomplete escape or quotation sequence is detected or should they be left unchanged?
    I guess being unable to save a command when it contains invalid escape sequences could work. I could imagine having a "Preview" option in the edit window that expands the edited command with the currently opened file would be helpful for developing and testing.

     
  • Ark

    Ark - 2013-01-04

    >>The working directory should be the directory that contains the original
    file (i.e. image or archive).
    >So change working directory before executing a command, then.
    At least that is what I think. If you launch two MComix instances, one of them at dirA and the other one at dirB, and then change the directory currently shown in the first instance from dirA to dirB, both instances will show dirB and the user cannot tell which one is which. This can really be a problem: While 7z allows the user to set the output directory to extract to (using -o), unrar (at least version "UNRAR 4.00 beta 3 freeware" on Linux) does not but always extracts all files to the current working directory. If the user cannot tell what MComix' working directory is, using unrar would end up in quite a mess ("Where did the extracted files go?").

    So I think it's fine for the user if he or she can easily predict where "unrar x %A" will extract files to. Maybe the user should be able to set the working directory for each command. This way, it would be flexible and lead to predictable results.

    Examples:

    Label: Extract archive (unrar)
    Working directory: %W
    Command: urxvt -e unrar x %A
    This would extract all files of the current archive to the directory where the archive itself is stored (opens a terminal so you can enter a password, if needed).

    Label: Extract archive (7z)
    Working directory: [empty]
    Command: urxvt -e 7z x -o%a.d %A
    This would extract all files of the current archive to a subdirectory of the directory where MComix has been launched (hence [empty] working directory). This subdirectory will have the name of the archive followed by ".d". Thus, if MComix is launched at "/home/me" and you are currently watching "/home/me/pics/niceones.7z", this command would extract all files to "/home/me/niceones.7z.d".

    If %W or %w is used in the command line, the substitution should take place before the directory is changed. At least this is what I suggest.

    >>Another issue: Should paths to directories end with the path separator or
    >not?
    >Yeah, the user can add path separators himself if needed.

    Should this apply to root directories as well (i.e. C:\ would become "C:")? Now that I thought about it some more, I think it should. It would be easier to implement, too. The user should then be instructed to use %D%/ in order to make sure that the absolute path to the image file will end with the separator.

    >After looking at your code a bit more, I thought about expanding
    >environment variables before any MComix subsitution. That way, file names
    >and such couldn't be affected. Unfortunately, expandvars on Windows
    >replaces %% sequences with %, potentially ruining otherwise legal
    >replacement strings. In any case, such a substitution might bring in
    >invalid characters all by itself, e.g. $CMD="echo %asd%".

    I checked it out and emelFM2 seems to do this just the way you said (i.e. environment variables before MComix variables), so I'm fine with it.

    >I guess being unable to save a command when it contains invalid escape
    >sequences could work. I could imagine having a "Preview" option in the edit
    >window that expands the edited command with the currently opened file would
    >be helpful for developing and testing.

    Indeed, that is a great idea.

     
  • Ark

    Ark - 2013-01-04

    Sorry for being somewhat ambiguous in my explanations when I said this:

    > If %W or %w is used in the command line, the substitution should take place
    > before the directory is changed. At least this is what I suggest.

    It was meant to be something like that:

    Both %w and %W should always be replaced with the directory (name or absolute path, respectively) that contains the original file (i.e. image or archive), regardless of what the user chooses as the working directory for the command line.

    Example: If the user chooses /tmp as the working directory for a command line containing a "%W", and MComix shows the content of an archive, then this %W should expand to the absolute path of the directory where this archive is stored. It should not expand to "/tmp", in general.

    (Maybe %o and %O would be better identifiers than %w and %W, respectively, as the "o" resembles the idea of "original directory" much better, I think.)

     
  • Oddegamra

    Oddegamra - 2013-01-06

    So, is it necessary to have %D at all? There is no %d (since this is already covered by %w), and %W does for images outside of archives exactly what %D does. Or am I misunderstanding you here?

     
  • Oddegamra

    Oddegamra - 2013-01-06
    • assigned_to: nobody --> oddegamra
     
  • Oddegamra

    Oddegamra - 2013-01-06

    SVN rev. 810 contains the latest changes with a more or less working implementation. Feel free to test and leave comments if something isn't working as expected (or at all).

     
  • Oddegamra

    Oddegamra - 2013-01-06
    • status: open --> pending
     
  • Ark

    Ark - 2013-01-08
    • status: pending --> open
     
  • Ark

    Ark - 2013-01-08

    Thank you for implementing these changes.

    > So, is it necessary to have %D at all?
    Yes, I think so. Please see the examples below.

    I wonder whether a new variable %O (for "original directory") might be useful. It should be expanded to the same value as %W, but should raise an exception when used inside of an archive. Use case: If you use MComix to open a file with GIMP, using %O/%f instead of %F would ensure that you do not open a temporary file and accidentally lose your changes to that file. Another variable, %o, should then be expanded to the name of the original directory.

    Example: We open the directory /home/me/pics which contains some image files (so we are NOT inside an archive). The current image we are looking at is named imgA.jpg. The variables should then be expanded as follows:

    %F = /home/me/pics/imgA.jpg
    %D = /home/me/pics
    %A is unavailable (invalid)
    %W = /home/me/pics
    %O = /home/me/pics
    %f = imgA.jpg
    %a is unavailable (invalid)
    %w = pics
    %o = pics

    Another example: We open the archive /home/me/old/archive.7z which contains some image files (so we ARE inside an archive). Since we are inside an archive, MComix already extracted the archive to a temporary directory, let's say /tmp/mcomix.xyz123. The current image we are looking at is named imgB.jpg. The variables should then be expanded as follows:

    %F = /tmp/mcomix.xyz123/imgB.jpg
    %D = /tmp/mcomix.xyz123
    %A = /home/me/old/archive.7z
    %W = /home/me/old
    %O is unavailable (invalid)
    %f = imgB.jpg
    %a = archive.7z
    %w = old
    %o is unavailable (invalid)

    Note that %D and %W may have different values, depending on the situation. Some invariants:
    %F = %D%/%f
    %A = %W%/%a
    Iff not inside an archive: %D = %W = %O and %w = %o
    Using %A (or %a) and %O (or %o) at the same time is not allowed.

    Examples that might show that all of these variables have reasonable use cases:

    $ urxvt -e mplayer -loop 0 -really-quiet %F # shows the current file with MPlayer inside urxvt.
    $ feh -r %D # opens all images in feh, using the very same directory MComix uses at that time.
    $ feh %F # opens only the currently selected file in feh. (Adding -r would change nothing in that case.)
    $ gimp %O/%f # opens the current image with GIMP, but fails if inside an archive.
    $ urxvt -hold -e 7z x -o%A.d %A # extracts files, fails if not inside an archive.
    $ urxvt -hold -e 7z a %W%/..%/%w.7z %W # compresses directory. Changing %w to %o here would ensure that you do not accidentally create an archive for images that are already stored in an archive.
    $ cp %F /mnt/sdb1/%a__%f # copies current file to /mnt/sdb1, prepending the name of the archive and two underscores.

    I hope these examples can clear up things.

    I found a bug concerning the error message shown when trying to run a command that uses %A: "Could not run command None: %a and %A can only be used for archives." Since I labeled this command "extract", "None" is likely to be a bug here.

    There are some issues concerning error handling. (For example, if not inside an archive, editing and saving(!) the commands is impossible if there is at least one command line that contains %a or %A.) I would prefer to see something like this:

    - If the user enters a command line containing a %x, he or she should get an error message immediately. (Using %A, %a, %O or %o is never an error in this sense.)
    - However, it should nonetheless always be possible to save all commands at any time.
    - If the user attempts to run a command that contains errors or variables that are currently unavailable, the user should get notified about this.
    - If there are several problems with a command line, one error message showing only one of these problems should be enough.

    Now for the preview:

    - The preview line should be updated every time a row in the commands table gets selected or updated.
    - If the corresponding command line contains a %x, the preview line should show an appropriate error message.
    - If the corresponding command line contains a variable that is currently unavailable, the preview line should show an appropriate info message saying something like "Preview not available: %a and %A can only be used for archives.".
    - If there are several problems with a command line, one message in the preview line showing only one of these problems should be enough.

    This way, there is no need for a "Preview" button.

    I think it might be cool (not to say sometimes necessary, as shown in my previous posts) to be able to set the working directory for each command line.

     
  • Oddegamra

    Oddegamra - 2013-01-08

    I found a bug concerning the error message shown when trying to run a command that uses %A: "Could not run command None: %a and %A can only be used for archives."

    Great, thanks for spotting that. Apparently, I my thoughts fell one step short here and I assumed the label wouldn't be needed anymore after a command as been clicked.

    For example, if not inside an archive, editing and saving(!) the commands is impossible if there is at least one command line that contains %a or %A.

    Again, my bad. This should now be fixed so that %a and %A only cause errors when actually running the command (and when previewing the command).

    However, it should nonetheless always be possible to save all commands at any time.

    For now, the user cannot save changes if either of these conditions are true for one or more commands:

    • The first argument isn't a valid executable. Valid executables are either absolute paths or something that is on PATH.
    • The command isn't syntactically valid, i.e. running the parser causes an exception.

    I guess the second condition could be omitted, but I'm not sure about the first. While it prevents dumb mistakes like misspellings, it could probably lead to problems when an executable is removed at one time, and the user tries to edit commands afterwards. He might not remember that the executable was removed, and wouldn't know why he cannot save his changes.

    So, scrap validation before saving completely?

    The preview line should be updated every time a row in the commands table gets selected or updated.

    Good idea. I removed the preview button and implemented an automatic preview instead.

    I think it might be cool (not to say sometimes necessary, as shown in my previous posts) to be able to set the working directory for each command line.

    Maybe I should add another column to the table then that would allow the user to specify the working directory (empty or . could represent the current working directory, I guess). Just to be clear, by working directory, I am talking about the directory MComix is started from, i.e. ~/test/asd $ mcomix would result in ~/test/asd being the working directory (the same output that getcwd() would produce). From your earlier posts, I'm not completely certain if you are talking about the directory where MComix extracts temporary files instead.

     
    • Ark

      Ark - 2013-01-08

      The first argument isn't a valid executable. Valid executables are either absolute paths or something that is on PATH.

      If you can make MComix recognize this kind of problem, I'd suggest that a warning should be added below the preview, something like, "Warning: COMMAND is not a valid executable or you don't have permission to execute it. Make sure you did not misspell it." Depending on the currently selected row, this warning message should appear or disappear or be updated along with the preview. This way, the user can check all his or her commands for this kind of problem by simply navigating through the list and watching out for any warnings to show up. Since the preview gets updated immediately after entering the command, he or she also gets notified about this kind of problem automatically.

      So, scrap validation before saving completely?

      Roughly spoken, yes. I think it would be sufficient to notify the user about problems
      - immediately after entering the command,
      - in the preview, and
      - when attempting to execute a command.
      But it should always be possible to save these settings, regardless of things like syntax errors or non-existent programs. In other words, there should not be any kind of issue that prevents the user from saving his or her commands.

      Maybe I should add another column to the table then that would allow the user to specify the working directory (empty or . could represent the current working directory, I guess).

      I second this.

      Just to be clear, by working directory, I am talking about the directory MComix is started from, i.e. ~/test/asd $ mcomix would result in ~/test/asd being the working directory (the same output that getcwd() would produce). From your earlier posts, I'm not completely certain if you are talking about the directory where MComix extracts temporary files instead.

      I'm sorry for my confusing way of expressing things. So, as of now, I'll try to use the term "working directory" less confusingly and in the same manner you just did.

      Because of this communication problem, I'm currently not sure whether to rename both %w and %W to something (hopefully) less confusing. How about %c and %C (as in "current"), respectively? Just to make sure, did you get the semantics of all the variables I proposed in my previous post? If you don't or if you have any suggestions to make it simpler, don't hesitate to ask.

      I tested using environment variables and I noticed that they seem to get expanded after substituting MComix variables. This is contrary to what you previously suggested and what I agreed on. Is this a bug?

       
  • Oddegamra

    Oddegamra - 2013-01-08

    Alright, guess I'll scrap disabling the save button then.

    Because of this communication problem, I'm currently not sure whether to rename both %w and %W to something (hopefully) less confusing. How about %c and %C (as in "current"), respectively? Just to make sure, did you get the semantics of all the variables I proposed in my previous post? If you don't or if you have any suggestions to make it simpler, don't hesitate to ask.

    Well, if %c as in "directory of currently opened file/archive", then I guess it will do. I'm having a hard time with the label descriptions on the right side of the edit dialog. The space isn't big enough to make them unambiguous and logical, unfortunately. Maybe I should go for mouse-over-tooltips instead.

    I noticed that I misinterpreted %D earlier, but after reading through your previous post again, I noticed and fixed that one. All variables should now expand to their correct definition, or so I hope.

    Concerning environment variables, I originally did expand them before parsing the string internally, but as it turns out (as mentioned earlier), Windows replaces %% with just %, rendering perfectly valid commands invalid as soon as %% is involved. So, I changed direction on that one.

     
  • Ark

    Ark - 2013-01-10

    Okay, this is kind of embarrassing ...

    First for the good news: I found a way that (hopefully) makes this variables thing much easier to understand. Now for the bad news: It requires another column "Disable for archives" (checkbox or similar) and will render some of the work you already did pretty much useless. I'm sorry about that.

    I think I will just skip lengthy explanations, so please have a look at some examples:

    Example 1: We open the directory /home/me/pics which contains some image files (so we are not inside an archive). The image we are currently looking at is named imgA.jpg. The variables should then be expanded as follows:

    %F = /home/me/pics/imgA.jpg
    %D = /home/me/pics
    %A is unavailable (invalid)
    %C is unavailable (invalid)
    %f = imgA.jpg
    %d = pics
    %a is unavailable (invalid)
    %c is unavailable (invalid)

    Example 2: We open the archive /home/me/old/archive.7z which contains some image files (so we are inside an archive). Since we are inside an archive, MComix already extracted the archive to a temporary directory, let's say /tmp/mcomix.xyz123. The image we are currently looking at is named imgB.jpg. The variables should then be expanded as follows:

    %F = /tmp/mcomix.xyz123/imgB.jpg
    %D = /tmp/mcomix.xyz123
    %A = /home/me/old/archive.7z
    %C = /home/me/old
    %f = imgB.jpg
    %d = mcomix.xyz123 (rarely useful, though)
    %a = archive.7z
    %c = old

    %C and %c were formerly known as %W and %w, respectively. %O and %o are not needed anymore since these variables would be equal to %D and %d, respectively, assuming "Disable for archives" is selected for the respective commands.

    Now it should be a lot easier to describe the meaning of these variables:

    Image-related variables:
    %F - image file path*
    %D - image directory path*
    %f - image filename
    %d - image directory name*

    Archive-related variables:
    %A - archive path
    %C - archive directory path
    %a - archive filename
    %c - archive directory name

    *: temporary when used with archives

    This would be easier for the user as well, e.g. gimp %F would work just fine, and disabling this command for archives would prevent accidental data loss, if necessary.

    Sorry for the inconvenience. :( I must admit that I needed some time to experiment and to understand the whole thing myself. But it seems to make much more sense now (at least to me).

    If it isn't too difficult to implement right now, please add an "Add separator" functionality. I'm currently using about eight "Open with" entries by now and it's already gotten somewhat messy. (The separators should then show up in the menu as well, of course.)

    I unintentionally found a problem concerning the process handling. If you run a command, let's say urxvt, it's easy to see (using htop with tree view enabled) that urxvt is a child process of mcomix' process. However, if you close urxvt, the child process does not disappear but becomes a zombie.

    Concerning environment variables, I originally did expand them before parsing the string internally, but as it turns out (as mentioned earlier), Windows replaces %% with just %, rendering perfectly valid commands invalid as soon as %% is involved. So, I changed direction on that one.

    Thank you for your explanation.

    And thank you again for implementing this feature! It really helps a lot!

     
  • Oddegamra

    Oddegamra - 2013-01-11

    I'm getting a bit pissed at SF's new Allura platform for eating my replies or wiki edits from time to time. Well, let's try again.

    I found a way that (hopefully) makes this variables thing much easier to understand.

    Great idea. Splitting the variables into an archive-related and non-archive-related section really improves readability. The aforementioned field was added as last entry in the table as checkbox field. If the checkbox is ticked and %a is contained in the command, executing said command will raise an error later on.

    If it isn't too difficult to implement right now, please add an "Add separator" functionality.

    How about this: You can use '-' as command label and leave the command field blank. This might not be the most intuitive solution, but it works well without screwing up the rest of the table code.

    I unintentionally found a problem concerning the process handling. If you run a command, let's say urxvt, it's easy to see (using htop with tree view enabled) that urxvt is a child process of mcomix' process. However, if you close urxvt, the child process does not disappear but becomes a zombie.

    Huh, that kind of sucks. Well, I understand why it would happen - the process is started, but likely never killed, because the code doesn't poll or wait for the process to exit (I don't even want to wait for the process to finish, because that would shut down the UI in the mean time). I'll think about something, if the current "workaround" I added based on something I found with Google doesn't work.

     
  • Ark

    Ark - 2013-01-12

    I'm not done testing yet, but I already made a few changes myself, based on r823. Said revision contains some bugs in the parser and the preview (e.g. "%%a" raises an error even for archives, the empty string practically gets lost in the preview). I also changed some variables so that they match the definitions given in my last post.

    I attached a diff file so you can apply the changes I made to openwith.py, r823. Hope that helps.

    Concerning the preview, I don't know how to escape the quote character (") on Windows, so I kept the \" replacement for all platforms. Despite the fact that it's just a preview, it would be nice if the preview matched the user's expectations for their respective platforms.

     
  • Oddegamra

    Oddegamra - 2013-01-12

    Google suggests that \" also escapes " on Windows, but I'm not too certain myself. To tell the truth, I'm satisfied as long as the preview is a vague approximation of the resulting command string. Seeing how said command will look differently to begin with (as nothing needs to be quoted), that should be sufficient in most cases.

     
  • Oddegamra

    Oddegamra - 2013-01-13

    Great, thanks! I moved the quote function out of the preview function, as it has become a bit too large for having it inlined there. You might also want to consider using diff -u for creating patches, since the default format is a bit of a mess to work with.

     
  • Ark

    Ark - 2013-01-14

    I found a bug in the preview code for Windows and fixed it. Furthermore, I modified the parser so you can use both spaces and tabs as delimiters.

    I think the parser should be used for the "Working directory" entry as well (but an error should be raised if there is more than one argument). This way, you can easily change to working directory %C, for example. And you should make sure that the working directory actually exists and that you can execute the command after cd to "Working directory"!

    Could you please add a confirmation window or something that shows up before actually closing the edit window? I almost always forget to hit "Save". (Would be cool if this window shows up iff any changes are made.)

    You might also want to consider using diff -u for creating patches

    Please let me know if there is an even better way to support you.

     
  • Oddegamra

    Oddegamra - 2013-01-14

    Alright, the working directory should now get parsed and expanded as well. I also added a confirmation dialog in case the user closes the dialog using the X button instead of the Save button.

     
  • Ark

    Ark - 2013-01-17

    Alright, the working directory should now get parsed and expanded as well. I also added a confirmation dialog in case the user closes the dialog using the X button instead of the Save button.

    Thank you for that. :)

    How about this: You can use '-' as command label and leave the command field blank. This might not be the most intuitive solution, but it works well without screwing up the rest of the table code.

    How about this: There are two buttons, "Add" and "Add separator". "Add" always adds a line with a non-empty label (e.g. "Command label"), whereas "Add separator" adds a line with an empty label (""). You cannot edit a line with an empty label. You cannot change a non-empty label into an empty one.

    Other issues:

    • Bug: It is possible to enter more than one working directory into the same line. Should be treated as an error instead.
    • Bug: Executability checking ignores "Working directory" value. Sometimes, no warning appears even if there is no valid executable.
    • Bug(?): Sometimes, all my "Open with" entries disappear and I don't know why. This seems to happen after restarting MComix or after rebooting the OS, somehow.
    • Bug(?): Closing "Save changes to commands?" by hitting the × button rather than "Yes" or "No" is equivalent to "No". Should be treated as hitting a cancel button instead.
    • How about a "Preview area" label right above the preview line?
    • How about a "Run now" button next to the preview line?
    • Bug: If you load a new set of images, the preview should be updated.

    After executing a command like mv or gimp, it might be necessary to reload the current image or the entire directory. Maybe this can be done automatically using file system hooks? Or does this need another column (Refresh=No|File|Directory|Archive)? Or should this be done manually?

    Concerning the F8 key: After some experimenting with this new feature (thanks again for implementing it!), I changed my mind. Now I think it would be better to have more than one keyboard shortcut. So, not the F8 key but the 1 to 9 keys should be used in order to execute the first, second, third, … ninth command, respectively.

    Use case:

    • Bind the "1" key to mv %F /home/me/dirA
    • Bind the "2" key to mv %F /home/me/dirB
    • Bind the "3" key to mv %F /home/me/dirC

    This way, you can move images to other directories quite easily. Another use case, for example: You need to open an image with mplayer (GIF) or Firefox (APNG), respectively. What do you think?

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.