[ShowImage] Save as... menu item should open a filepanel

[diver]

This is hrev39274.
File->Save as... menu used to work, but not anymore.

[mmadia]

Works for me in hrev39385 gcc2hybrid.

What exactly doesn't work?

[diver]

If memory serves me right, Save as... menu item used to open file panel.

[humdinger]

With hrev39402 "Save as..." will open the save panel only when you choose a format from the submenu. Maybe what diver means is having the save panel also coming up when choosing directly the "Save as..." item. This could save an image in the original's format. Maybe it that in the past already?

[axeld]

I haven't changed anything there. However, I think that submenu is completely superfluous, and should be added to the file panel instead (as its done everywhere else, too).

[Ka]

Testing with Revision 39605, no problems at all. Everythings works as expected.

[leavengood]

I think what diver is referring to is the main Save as... menu item not doing anything when clicked. It should probably just do what humdinger suggested and allow saving the image with a different name in the same format.

[halilpk]

(GCI-2011 Participant)

Haiku revision: hrev42211 not a bug. I have tried many different things.All of them firstly the save panel opened and it saved correctly where you want . System: Haiku hrev1-alpha3 on VMware workstation 8 on windows 7 32 bit

[diver]

halilpk, obviously you haven't read comments to this ticket as well as to several other.

[leavengood]

Doesn't seem like Axel is working on this, so I'll take ownership. I'm going to put some time into ShowImage.

[hometue]

(GCI-2012 Participant) Haiku revision: hrev44702. Valid, but not a bug. The current steps to using "Save as..." is to hover on it,then clicking on the file formats listed in the menu to the right, although having a save file menu popping out when the user click "Save as..." will give a better user interface. System: Haiku R1-alpha4 on Virtualbox 4.1.20 on windows 7 64 bit

[leavengood]

As an update, I obviously have not been working on this, but that is because to fix it requires a fairly major change to ShowImage. Namely that we need to improve the design of the code so that there is an object with more knowledge about the shown image. Right now ShowImage does not actually know the file format of the image it is showing.

So to fix this (and likely several other issues) I plan to introduce an Image class which will be sort of a model class in the sense of Model-View-Controller (MVC.) This will contain knowledge about the file, such as it's format and filename (the latter will be used to fix another bug.) I will likely also create an ImageDirectory class that can be used to show the number of image files and the current index of the shown image in the status bar (similar to the excellent Mac OS X image view Xee.)

Along with creating these classes I intend to make ShowImage use more of an MVC style, as right now it is a bit of a mess with a huge amount of logic stuffed into ShowImageView and ShowImageWindow. These changes should make it easier to add features and fix most of the existing bugs.

[pulkomandy]

I like Axel idea (remove the menu and add a popup menu to the save panel. However I can't agree with the "as it is done everywhere else" part. The only app I've found which does this is Wonderbrush (and it's not open source so I can't borrow the code from there).

At least the following need to be updated:

• ShowImage: has a menu in the menubar
• Magnify: saves the bitmap as a .h only
• Screenshot: has a popup in the main window
• CodyCam: has a popup in the main window, no way to get to the translator settings (and also currently no file panel)

Icon-O-Matic has a similar save panel but hardwired to a preset list of formats instead of listing all image translators found in the system. Given the same file panel could be used by all 4 apps above (and maybe more? Did I miss one?), it should be made part of the shared kit so the apps can all use it.

This is orthogonal to Ryan's suggested changes, since it doesn't need to know the original format of the image. It would be nice if it did, however, so it could have a "original format" option in the menu performing just a copy. But there are better tools to copy files.

[axeld]

The "as it is done everwhere else" part refers to pretty much every software (outside of our repository, though) :-)

Most apps get the file format from the extension you type, anyway. If you need examples, look at Gimp, Photoshop, MS-Office, OpenOffice, ...

[leavengood]

Maybe a compromise is the following:

• A "Save as..." menu item (with no sub-menu) which opens a save panel that then has an image format choice, defaulting to the current type (which still requires my Image class idea.)
• An"Export as..." menu which is the current "Save as..." sub-menu, which just opens the above panel with the image format that was clicked in the menu as the current choice.

I think the menu is very nice and fast to use, and discoverable, but then having the choice in the file panel allows the user to correct a miss-hit on the menu without closing the panel.

[humdinger]

Having separated menu items for "Save as..." and "Export as..." can make sense, but not often.
WonderBrush is an example where it makes sense, because you have WB's own fileformat that you want to keep saving at one location, and a production-fileformat (like PNG or JPEG) that you alse want to keep saving at some other location. You may want to check that changing PNG by reloading a document in the browser, for example.

This isn't the case with ShowImage. Here I'd prefer one "Save as..." menu item that opens a file dialog with a popup menu to choose the format, the original's format preset. Bonus points for setting the right file type suffix when changing the format. :)