One feature I miss about another image viewer, Gwenview, is that it could display thumbnails for all the images in a whole folder -- and then navigate up or down the directory tree from there. When you wanted the normal close-up view of a particular image, you double-clicked the thumbnail.

Ivy already does something like this for browsing tags. I think it would be a nice way to jump around in the current directory, or into other directories.

The Metadata Editor is currently... sparse. Considering that at least a few of the Dublin Core choices can be entered multiple times to account for different languages, the current options simply aren't enough.

Perhaps have a list box like in the tag browser?

Test adding SVG support (via rsvg package).

This is from the release notes for v2.1.1.

This error appears when opening Ivy for the first time on Windows:

file-or-directory-permissions: update failed due to unsupported bit combination
  path: c:\users\lehi\appdata\local\ivy\thumbnails
  permission value: 448
  context...:
   #%embedded:g7024:files: [running body]
   #%embedded:g6099:db: [traversing imports]
   #%embedded:g5618:base: [traversing imports]
   #%mzc:main: [traversing imports]
   loop

Perhaps only run the permissions procedure when on *NIX.

In the case where a single image file is specified as the source argument to -M, allow the destination to be a desired file name. The actual function being used, (rename-file-or-directory old new), allows this without modification.

This enhancement request doesn't take a strong stance on correct default behavior if the destination file already exists; probably it should just do whatever ivy already does if you tried to move "foo.jpg" into a directory that already had a file with that name.

Proof-of-Concept @ IonoclastBrigham#1

Implementation notes and discussion:

• The keyboard shortcut selected was ↑, because it was really convenient if you're already using the left/right arrows to browse around. It's a less straight-forward conceptual mapping though, and user's won't intuitively know that "up means random".
• I just stuffed the button between left and right arrows, but it doesn't really need to be there if that might be confusing or cause user error.
• The button's icon was chosen to match the ↑ keyboard shortcut, and to distinguish it from the left/right buttons. But as a glyph to symbolize what it's doing, it only make sense at all if you've already assimilated the fact that ↑ is the keyboard equivalent

Given these issues, it may make sense to move it into the menu with an accelerator shortcut like CTRL+R, or something. It could go under File, or a new View or Browse menu, maybe. On the other hand, I am tempted to keep the ↑ mapping in any case, just because it's so convenient.

I think it would be fun to have a window that tells stuff about the database like

• Total number of images/tags
• Average tags per image(?)
• Largest number of tags on an image
• Largest number of images in a tag category

I think it'd be easy to implement, too.

I would like to add FLIF support to Ivy, but a problem I foresee is troubles with packaging the binary. It'd be simple enough to add FLIF to the Windows binary, but I'm not certain how I should proceed with Linux/OS X. As I understand it, OS X's .app files work as a special kind of file/directory hybrid so it's plausible I could add the FLIF library to that, but I'm not certain where. @IonoclastBrigham Could you weigh in on this?

There is a Homebrew available that has a(n outdated) FLIF recipe we could investigate to help automate the build process a little.

It may at some point become desirable to create translations for many of the different menu items and such, including the help-string text. Here's how I envision this could go:

1. Create a giant hash that is dynamically loaded on-run (through read or some such)
   1a. One file per language might be best
   1b. Place them inside the ivy directory
2. Determine the language from configuration file? Perhaps from environment variables? (Need to look up language environment variables for the three platforms)
3. hash-ref for when there's things we want to translate

Some concerns:

1. What to do when there are no translation files available? Built-in default English translation hash? Fail with an error?
2. Will this make startup times increase too much? If necessary, look into setting the language as a compile-time thing, perhaps reading the environment variable (or some other setting) so we can speed things up.

Most other things in Ivy have both mouse and keyboard controls. But currently the only way to return focus to the images for navigation is to click with the mouse. I think hitting Esc or something like that would be appropriate.

Steps to reproduce:

1. Open Ivy
2. Append images to collection (no visible changes to UI)
3. Append more images to collection

Error appears

+: contract violation
  expected: number?
  given: #f
  argument position: 1st
  other arguments...:
   1
  context...:
   /home/lehi/prog/racket/ivy/frame.rkt:145:8
   /usr/share/racket/pkgs/gui-lib/mred/private/wxme/keymap.rkt:736:2: core502
   /usr/share/racket/pkgs/gui-lib/mred/private/wxme/keymap.rkt:508:2: chain-handle-key-event method in keymap%
   /usr/share/racket/pkgs/gui-lib/mred/private/wxme/keymap.rkt:496:4: for-loop
   /usr/share/racket/pkgs/gui-lib/mred/private/wxme/keymap.rkt:508:2: chain-handle-key-event method in keymap%
   /usr/share/racket/pkgs/gui-lib/mred/private/wxme/keymap.rkt:508:2: chain-handle-key-event method in keymap%
   /usr/share/racket/pkgs/gui-lib/mred/private/wxme/keymap.rkt:459:2: handle-key-event method in keymap%
   /usr/share/racket/pkgs/gui-lib/mred/private/wxmenu.rkt:54:22
   /usr/share/racket/collects/racket/private/more-scheme.rkt:148:2: call-with-break-parameterization
   /usr/share/racket/collects/ffi/unsafe/atomic.rkt:72:13
   /usr/share/racket/pkgs/gui-lib/mred/private/mrtop.rkt:182:24: on-subwindow-char method in frame%
   /usr/share/racket/collects/racket/private/more-scheme.rkt:148:2: call-with-break-parameterization
   /usr/share/racket/collects/ffi/unsafe/atomic.rkt:72:13

Expected behavior:
Append images to empty collection loads the first item being appended

It can be easy to miss that the text bar or something else still has focus. Perhaps the text bar, and/or the GUI buttons, could be highlighted a little more, so users don't wonder why the arrow key navigation isn't working.

When an image is scaled, it looks all jagged 'n' stuff. Maybe instead of using draw-pict to display to the canvas, use draw-bitmap, but still use picts for resizing. draw-bitmap makes things look smoother, but scaling a lot will make it super blurry.

For all but the most familiar icon designs, it may not be immediately obvious what that icon really means. Adding tooltips which appear when the user's cursor hovers over a button -- or else having text beside the icons on each button -- would help. Users may get nervous if it's not clear what an unlabeled button is going to do to their precious data, etc, etc.

It would be nice to generally clean up and extend the command line capabilities of ivy, such that it is more useful for unix style scripting. Here's a potential list:

• print search results more suitable for scripting
  • no summary line, e.g. Found 3 results for tags '("blerg")
  • exit when done
• delete tags from image
  • -D or --delete-tags
• add tags to image
  • -A or --add-tags
  • adds given tags to the list
• set tags on image
  • -T or --set-tags
  • replaces any/all tags currently set with the specified tags
• rename/move image on filesystem / update DB
  • -M or --move-image
  • keeps files associated with their database entries without having to cut, move, re-open, re-tag
  • possibly a lot of effort for an obscure feature

I rather like the convention of capital letters for possibly-destructive short options. Makes them more emphatic and requires a little more thought to type them.

I'd like to be able to do something like the following:

for img in (ivy -oe blerg)
    if test (file --mime-type "$img" | awk '{print $2}') -e "image/gif"
        ivy -D blerg "$img"
    end
end

Weird things happen when trying to render the SVG from Awesome Inc (see #47). It's actually a problem with librsvg and not with Ivy, but I am creating this issue for future reference in case something like this happens again. 99.9% of SVG's I've tested (and have on my own computer) work just fine, but perhaps we'll see another aberration like this again.

I'm seeing inconsistencies with tagbar state.There's actually two ways it manifests, but it's not clear yet if they're related or independent.

Repro steps to get into an inconsistent state:

1. new pic, no tags
2. type => gold
3. tab to another app
4. tab back, still yellow
5. delete chars, hit esc to defocus

Expected result: if I'm escaping-out of the tag bar and it's not different from the canonical dictionary, it should be white.

Actual result: still gold, title still prefixed (*)

The other issue, briefly, is that zooming always resets tag bar color to white, regardless of the actual state.

keep-duplicates will give false positives when tags that you do not want in an 'and search are contained within several (but not all) of the tags you have specified. This occurs when searching for images with 3 or more tags supplied.

ex:
ivy -a "beach, ocean, ball" is expected to supply images where all three tags are contained within the image, but it also may supply images that have two of those tags, even though all three are required.

Possible solution:
Instead of grabbing the images from all the tags at once and then running keep-duplicates, grab all the images from a single tag, then the next tag, run keep-duplicates, then grab the images from the next tag, etc.

FLIF's with transparency have very bizarre decoded results:

When decoding to a PNG, the transparency is there like normal --- as well as when looking at it with UGUI_FLIF or viewflif. Only when viewing with Ivy does the image look so weird. This behavior has persisted even after switching to using flif-read-rgba8. I suspect it may have something to do with rgba->argb!, but the concept behind swapping the bytes around is so simple I doubt that's really it.

This is just a bit of visual polish for Mac users with high-density screens. I think we can just copy or link to the corresponding next-size-up asset in the implicit "@1x" icon set for all but the largest one. We'd just need to add the final image which we can generate at build time from the .SVG original.

Concerns and possible risks:

• I'm not 100% sure making a copy of e.g. the 512px asset and renaming it [email protected] will work, or if the system will respect the embedded screen density setting. Need to look this up in the docs
• Generating the last, biggest @2x item at build time, and possibly making double-density versions of the ones we already have should be a fairly simple terminal command in the makefile, though it may add another 3rd party dependency.
• For example, using ImageMagick we can do something like convert -size 512x512 img/ivy-logo.svg mac.iconset/[email protected], possibly adding arguments to set the embedded density tag; OS X doesn't ship with ImageMagick though, so users would need to get it from MacPorts, Homebrew, source tarball, etc.
• Testing shows that while the icon itself has a specific height, exporting it this way @ 1024x1024 stretched the canvas, resulting in a double-size image with the icon up in the top-left quarter. This might be fixed with a scaling parameter to ImageMagick, or it might require tweaking the SVG definition.

I believe all of these affect both the README and the man page:

• Gui Interface section
  • Third bullet, "home" and "end" aren't capitalized, which is inconsistent with e.g. "Ctrl" and "Enter", used elsewhere
  • Sixth bullet, instructions direct you to enter tags "...separated by a comma and a space," though whitespace isn't used for parsing and is actually trimmed, making it unnecessary
• Tag Browser section
  • "Ctrl-b", the B should be capitalized
• Animated GIF Support section
  • Typo in "Due to the unstable natue of the related code..."

STR

1. Click, or hit enter or , to focus the tags field
2. Enter one or more new tags
3. Hit enter or the "Set" button to save

Expected Result

• Tags saved
• "*" removed from file name in title bar
• Tag field green and de-focussed.

Actual Results

• When hitting enter key:
  • ✅ Tags saved
  • ✅ "*" removed
  • ⚠️ Tag field still yellow
  • ⚠️ Tag field still focused
• When hitting "Set" button:
  • ✅ Tags saved
  • ✅ "*" removed
  • ✅ Tag field green
  • ⚠️ Tag field still focused

Discussion

This only seems to happen sometimes. I haven't been able to narrow down what the minimal steps to reliably trigger it are. But, once I got in this state, it happened nearly every time I tried to save.

I can say I first noticed it when I opened a collection from the command line like $ find ~/images -type f -name '*foo*' | xargs ivy. It's possible the large number of commandline args (over 100) caused something to get gummed up.

Normally when you right-click on a file in your file manager, the context menu has an entry to choose which application with which to open the file. Ivy does not appear in the list of available applications for viewing images.

At least, not with Nautilus 3.18.5, with GNOME Shell 3.18, running on Fedora 23 x86_64. Probably you need to add an entry to some XDG or FreeDesktop config file.

I can test on Cinnamon and KDE too once we figure out the necessary config files.

Looks like there's prior art out there for implementing these libraries for racket, but I can't be certain as to their quality or relevance. Hacking minimal wrappers for one or both formats may be easier than trying to wrangle someone else's code.

Adding or removing tags in batch is kind of slow. I'm certain it'd be a little faster if I gave -A and -D the same treatment as -M. Of course, this should be extended to all of the operations Ivy does. Batch image processing shouldn't have to be done in a for loop in the shell --- because that would make Ivy spawn a new instance every time, which is slow. Just give Ivy a whole bunch of images to process and it'll do that in one go.

Steps:

1. Open an image
2. Edit tags
3. Optionally, save tags
4. Hit CTRL+O, select a new image, accept

Expected results: tag field state reset (unfocused, white background).

Actual results: contents are reset, but state is left as it previously was (background either gold or green, focus as it was on the previous image).

Change the pathing in some cases that determine which OS we are using from a simple if statement to a macro possibly? That would make it so the code is executed at expansion time instead of runtime (I think). Hopefully this would make ivy slightly faster at startup.

Usecase

I frequently come across an image I might like to re-crop, touch-up, adjust levels, etc. What would be really nice would be the ability to open it in an external editor right from Ivy, but I feel like that would take a lot of thought to get just right, and might be fiddly across platforms and individual configurations.

The next best thing is to copy the file's path to the clipboard, and let me just open it in my editor from the terminal.

Implementation

Typically this functionality would be Ctrl-C, but that will be preempted when the tag field has focus. The other likely way would be under the Edit menu, but we currently don't have one. Or possibly by right-clicking the canvas and choosing from a context menu, but that's not currently a UX idiom Ivy has at all.

Conclusion

Long story short, this seems very clearly to be both very useful and also easy to implement, I'm just not sure where/how to hook it into the UI. Looking for feedback.

I'm not sure this is even possible with racket-gui or not...

Emoji aren't properly rendered on macOS in text-field%s. They are fine in other widgets, like the tags list in the browser window.

Tested as rendering correctly everywhere on Gentoo. [Edit: and Windows.]

Internally, ivy doesn't seem to have any issues with emoji. It'll stick them in the DB and XMP data no problem. If you paste emoji into the tags field, they don't render at all (they're double-wide blank spans), but I have verified they were saved correctly.

$ ivy --list-tags test.png
tag1
tag2
tag3
💩
🤷🏻‍♀️

Viewing images in full-screen mode would be nice.

Side panel or new window that shows a (searchable?) list of tags (that are expandable?) to show all the images inside.

I'm thinking like View -> Tag Browser

+ beach
- ocean
      dog.jpg
      dolphin.jpg
      fishing.jpg
      ...
+ scenery

I think it'd also be nice to be able to edit the tag categories themselves in case of, say, a rampant typo, either by renaming the tag category or by migrating images from one tag to another.

So currently, it looks like pretty much every GUI component in the app is allocated and statically initialized at startup whether it's ever used or not, because of how the code is written. This leads to poor startup times, and is especially wasteful when using ivy as a command line utility.

This can be ameliorated by instead of top-level define-ing everything for each module, export one or more functions that will create the required GUI objects on demand. Or a concrete subclasses that can easily be instantiated with all the desired default attributes.

The following error appears in the debug window when trying to fullscreen the window.

ptr-set!: given value does not fit primitive C type
  C type: _int32
  given value: 2147483648
  context...:
   c:\program files (x86)\racket\collects\ffi\unsafe.rkt:1260:0: cast
   c:\program files (x86)\racket\share\pkgs\gui-lib\mred\private\wx\win32\frame.rkt:627:2: fullscreen method in frame%
   c:\program files (x86)\racket\collects\ffi\unsafe\atomic.rkt:72:13
   c:\cygwin64\home\rihai\ivy\frame.rkt:589:4: on-char method in ivy-canvas%
   c:\program files (x86)\racket\collects\racket\private\more-scheme.rkt:148:2: call-with-break-parameterization
   c:\program files (x86)\racket\collects\ffi\unsafe\atomic.rkt:72:13
   c:\program files (x86)\racket\share\pkgs\gui-lib\mred\private\wx\win32\window.rkt:765:2: dispatch-on-char method in window%
   c:\program files (x86)\racket\share\pkgs\gui-lib\mred\private\wx\common\queue.rkt:454:6
   c:\program files (x86)\racket\share\pkgs\gui-lib\mred\private\wx\common\queue.rkt:505:32
   c:\program files (x86)\racket\share\pkgs\gui-lib\mred\private\wx\common\queue.rkt:653:3

Ivy lets you start a temporary collection of images from disparate folders, so you can cycle through those images together. This is pretty cool! But right now, the only way to do it is from the commandline. Adding a menu/button and a keyboard shortcut to "Add images to your viewing session" or something like that would be nice too.

Ideally, a graphical interface should be "self-documenting" however much that is possible; however, Ivy has some legit command line features, and the GUI will become less obvious as you add more features. I propose a three- or four-prong attack strategy:

• update the command line informational messages. The --help message is a little strangely formatted, and the purpose of the slashes isn't super clear. Adding a --version flag might be good too, now that you're tagging versions.
• Write a man manual page. Maybe a GNU Info page too?
• Keep up with documentation here in the README file.

Something like PanDoc might be helpful for mirroring the content between different file formats.

Perhaps a new menu-item Image that will allow the user to flip the image horizontally and vertically, as well as rotate it to the left and right.

Image
--Rotate left
--Rotate right
--Flip horizontally <->
--Flip vertically ^|v

... or something

Currently, when you select a particular image for a tag in the browser, and click the thumb, it opens that image as if you had selected it from the system file chooser. This brings every image in that directory into the collection, regardless of whether they have that tag, and doesn't include any images in other directories that do have the tag.

It seems like a pretty straight-forward change to make it load the image as if it were a search result for exactly and only that tag, and would bring the tag browser behavior in line with the search results dialog.

Consider replacing the current image-path-hash-thread with semaphores.

Issues that come to mind:

• This probably isn't something I should bother with outside of wanting idiomatic(?) racket
• Changes to the metadata must be queued and done in order
• Is having them be threads necessary in the first place? It might be even easier/better to just have a queue instead of a hash that executes the metadata writing.

In the Racket Guide, the initial example has semaphores for threads that print, but the order of the threads that execute appear to be in reverse order of creation.

Change -M <source> <dest-or-dir> to something more unixy -M <source ...> <dest-must-be-dir>, where the final arg is the destination directory.

Compiling Ivy is pretty easy, as long as you already have Racket installed. But adding Ivy to the system package managers would be better still.

I can write an RPM spec easy enough, and probably even get the package added to the Fedora repos. For other Linux distros, there's the Open Build Service by OpenSUSE. For Windows, there's Chocolatey. For OS X, there's Homebrew.

One possible issue, though, is that most Linux distributions tend to frown on static linking / bundling dependencies.

When zooming in and out, grab the position of the mouse (if it on the canvas) and set the scrollbars to that position.

Should only have to mess with init-auto-scrollbars, but the tricky part might be getting the mouse position and determining whether the mouse is on the canvas. Perhaps 'wheel-up and 'wheel-down pass an additional argument (or set some parameter) so we know for sure the mouse is on the canvas?

 * QA Notice: This package installs one or more .desktop files that do not
 * pass validation.
 * 
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/flif" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/gif" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/jpeg" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/png" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/svg+xml" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/x?xbitmap" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: (will be fatal in the future): value "image/bmp; image/flif; image/gif; image/jpeg; image/png; image/svg+xml; image/x?xbitmap; image/x?xpixmap;" for key "MimeType" in group "Desktop Entry" contains value " image/x?xpixmap" which is an invalid MIME type: " image" is an unregistered media type
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: value "Graphics; 2DGraphics; VectorGraphics; RasterGraphics; Viewer;" for key "Categories" in group "Desktop Entry" contains an unregistered value " 2DGraphics"; values extending the format should start with "X-"
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: value "Graphics; 2DGraphics; VectorGraphics; RasterGraphics; Viewer;" for key "Categories" in group "Desktop Entry" contains an unregistered value " RasterGraphics"; values extending the format should start with "X-"
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: value "Graphics; 2DGraphics; VectorGraphics; RasterGraphics; Viewer;" for key "Categories" in group "Desktop Entry" contains an unregistered value " VectorGraphics"; values extending the format should start with "X-"
 * 	/usr/share/applications/ivy-image-viewer.desktop: error: value "Graphics; 2DGraphics; VectorGraphics; RasterGraphics; Viewer;" for key "Categories" in group "Desktop Entry" contains an unregistered value " Viewer"; values extending the format should start with "X-"
 *

@terrycloth Perhaps it's complaining because there's spaces in between? Before there were no spaces: Categories=Graphics;2DGraphics;RasterGraphics;Viewer;

Action: Drag-and-drop image onto the canvas
???
Result: Image is loaded!

See: accept-drop-files and on-drop-file

Steps:

1. type into the tags box for current image
2. delete all changes you just made, restoring to original contents
3. hit ESC

Expected behavior: tag field reverts to white, '*' char is cleared from title bar.

Actual behavior: the '*' char is not cleared.

Tested against: master / 40bbaf2 on OS X.

Same issue as #62, except in the tag browser img-lbox.

Note, I already have a fix for this which will be in a forthcoming PR, along with a few other tag browser enhancements. Just wanted to have it logged here for posterity.

GIFs really should animate. I realize this is a limitation of how the app is structured around the canvas and how images are loaded into it, and thus might be some time before a suitable solution is found.

Please post relevant links below.

The program will throw a contract error if the title of the file is too long, so truncate it at a certain point.

Much of Ivy's code is untested. The libraries have their own tests, so that functionality isn't going to be in the scope of this issue. What does need to be tested, however, is the consistency and functionality of the database and embedding functions. This will require creating (or reusing generated) images and a database.

I'm thinking something like the following:

ivy/test/
↳ test-embed.rkt
↳ test-db.rkt
↳ test-img # (every extension embed.rkt can handle)

@terrycloth The button icons could use being replaced. Instead of picts that are generated on startup, they'd be bitmaps that actually look, you know, nice.