I don’t know, I think dragging out snippets is pretty useful, and not exactly “editing”, but I can see your point. I worked on ShowImage back in the day, I guess I need to get caught up on the current state.
If resizing was removed I would think that is a pretty major regression in usability.
Obviously we should not copy Microsoft and their schizophrenic design, but I don’t know how clear the line is between viewing and very simple editing. Drawing things and vector graphics is obviously too much, but resizing and snippet dragging or copying doesn’t seem bad.
I do agree the drag to trash to erase is pretty silly. It is probably something BeOS did to demo negotiated DnD.
I guess either way I need to get caught up on what ShowImage currently does.
Also thanks for working on this tool derpo, I too would like to understand the negotiated DnD better.
Dragging a clip from ShowImage to Tracker still works.
For me the line is pretty clear: you can extract as much data as you want from the image. This includes taking clips, saving as different formats, maybe resizing (that feels already borderline). But you shouldn’t go further than that.
Anything else (dragging clips into the image, adding marks, etc) is editing. Editing needs to be done with care: undo history, managing a “modified” state, handling shutdown messages to make sure your data isn’t lost, etc. Therefore, it is outside the scope of a viewing application.
I can actually imagine the dragging to trash to be useful in some way. For example, let’s imagine you are back from vacations and you took a lot of pictures. You put your SD card in your Haiku machine, and you can quickly flick through all of them, and delete the ones that are useless (blurry, fingers of operator visible, etc). I can imagine dragging to other directories to be useful as well to quickly sort your pictures (maybe you didn’t unload the SD card for a year or so, and you just found old christmas pictures there?). This could also be done from Tracker if we had thumbnails, but right now we don’t. It is an use case that fits both in a file manager and in a picture viewer. So, DnD from one to the other makes sense. It avoids turning Tracker into a picture viewer, and it also avoids turning ShowImage into a file manager.
OK, I think we are in agreement then. Probably not much has changed in ShowImage since I worked on it.
I understand where you are going with the drag and drop stuff but it would require some more thought. Trashing a few images is one thing, but mass moving by dragging and dropping each image one at a time seems kind of painful. Also 99 times out of 100 I would probably rather hit the delete key (or whatever other keyboard shortcut it is) to delete an image (move to Trash.) I also don’t know how discoverable it would be that the whole image is draggable.
Lastly image thumbnails in Tracker is something else I may want to work on at some point. But I wanted to get some advice from other devs before trying anything. First, to see if we can borrow anything from the Tracker.newFS code, if it isn’t totally lost, and also maybe we can still try to bring in some of the aldeck refactoring work. You probably know more than I do about some of that.
Trashing an image already works with ALT+T or DEL. We could add a trash icon in the tool bar for mousephiles. A single-level undo would be nice BTW, in case of a mis-click/keypress.
Sorting via d’n’d is always a bit tricky. Discoverability is one thing. It also clashes with current functionality. A left-drag moves the picture, if it’s larger than the window. A right-click shows the context menu.
One solution would be to have a representation of the current picture in the toolbar and d’n’d that. Doesn’t work when the toolbar is hidden though.
And generally, you’ll have to have the destination visible (open Tracker window or folder icon).
What would be nice: “Copy to >” and “Move to >” items in the File and context menu like in Tracker, complete with a “Recent folder” item plus the Tracker-global “Favorites”.
For R1 we may keep enhancements to a minimum to keep some focus, but if you guys can investigate what features Preview has which ShowImage lacks, it can give us a target to work toward later.
As PulkoMandy says, we want to avoid any major editing features in ShowImage, and I think that would include color adjustment, markup and annotation, which I see Preview has.
For what it is worth, I have some old tickets I will pick up again this year to resolve some architecture issues within ShowImage that may make some enhancements easier. If anyone cares that is the addition of an Image model with the app to provide some separation and make certain features easier. I talk about it here:
Depends on what version of Preview I’d be looking at recommending to everyone. In recent years, it’s received quite a few improvements, to the point it’s become a rudimentary graphics tool for smaller tasks, like quickly adjusting the alpha value or color of a photo.
I’m all for adding a simple image editor to Haiku, but it would be nice to keep the viewer… well a viewer
In fact, I like the idea of MultiView on Amiga, it’s a viewer tool that can open any fileformat (thanks to datatypes - the thing that inspired our translators), but cannot do any editing. Just rendering. It works for pictures, sounds, textfiles, AmigaGuide (a simple hypertext format used for helpfiles), etc. By being strictly a viewer, it can be more versatile in what it supports. When however you need editing features, you turn to the appropriate editor.
For me, the feature downgrade in the current ShowImage was a significant loss to the standard Haiku distribution. I’m sorry to say I can’t remember the old features, I just remember wondering what on earth inspired someone to substitute this loser for what had been a useful application. But specifically, resizing - if there’s one editing feature that anyone with a modern digital camera needs, that’s it. Standard capture sizes of 4K x 3K are commonplace, while normal uses for an image are better served at a (linear) quarter of that size. Users are routinely encouraged to edit their images accordingly, and all too often they report that they can’t figure out how to do it. When it’s a MacOS, you can tell them “you don’t need Photoshop, just use Preview!”
It was removed almost a decade ago, you can be forgiven for not remembering. I was starting to wonder if I could even find the relevant commit:
I do think it is a problem to not have any way to resize images in a base Haiku install. I suppose many people will not want this added back to ShowImage. Maybe we need a very basic “EditImage” app, or just ImageResizer, which could also be scriptable, both from command-line and hey scripting.
How about making ShowImage aware of Tracker add-ons that support MIME image/* and add an “Add-on >” menu with the found add-ons in a sub menu.
Then provide 3rd part packages for all sorts of image manipulations.
See the problem? They can’t figure out how to do it. That’s what I’m saying here. An application named ShowImage or Preview is not an editor. So, we need an application named PictureEdit or something like that, with these resizing, red eye, etc operations. But this should not be in an application designed to view images.
And no, it will not serve the same needs. ShowImage has ways to move to next/previous image, do slideshows, etc. These functions I do not expect in an image editor, because if you have modified the image, what should it do? Save it automatically when you press the left/right keys to go to the next one? Pop an annoying BAlert?
We would have a very complex app if we try to do both in a single application. We can have two simple apps instead.
And don’t suggest that ShowImage should have a slideshow mode and a separate editing mode. That’s the same as having two apps
Back in the days there was TAR (The Awsome Resizer), I think PulkoMandy still hosts it somewhere
Even thought about make a recipe for that at one point, not sure it will work on x86_64 though (can’t remember if the sources were included)
As a user, the most I would want an application like ShowImage to do would be format conversion (jpg, png, gif, etc… as well as bit depth), scaling, cropping and possibly whole image filtering (ex: sepia tone, border effects, etc…), all without altering the original image. The results of the mentioned actions would only be savable via export/save-as into a new file.
The filtering capability might be tough/impossible to do without opening a can of worms, unless all the filters are required to be built-in, not plug-ins.
By ruling out modifying the original, the “undo” problem really goes away. All actions can simply be kept in a list for the image, and that list can be altered very simply: entries can be added, edited (change parameters), removed or reordered. No undo for image edits needed. Deciding whether to replace the original with the altered version is something the user can already do in the Tracker (preview thumbnails would help).
Conversions and cropping are already possible, from the file menu and by selecting a part of the image then dropping on Tracker. I think that’s enough for this app.
There is an ImageMagick frontend if you want to do filters, you can find it somewhere on the forum but I don’t know if there was a package for it yet.
And for non-destructive editing, there is of course the amazing Wonderbrush. And we should put some effort into ArtPaint and Becasso, most likely. Would be great if 3rd party devs took care of this, and not, once again, the small and busy Haiku core team!
The thing about the limited, non-destructive filter capability is (at least when it’s as limited as I envisioned it being), they’re the sort of things that are very useful in creating and presenting slideshows.
