On Saturday, February 3, 2007, 12:48:54, Thorsten Wilms wrote:

Then the Save_as_JPEG controls could appear on the image window (inspired by the Firefox find bar) to further cut down on window juggling.

Only as an option - some of us have multiple displays, and use the advanced options regularly.

Thorsten Wilms wrote:

I think the Save_Image dialog should just disappear after use, as both Cancel and Help are available on the second dialog and what else would it be good for?

Yeah it can go. It would only make sense if a Cancel on the jpeg options would get you back to the Save_Image dialog, in case you see that the jpeg compression is not appropriate, you change your mind and go back for png or so...

Then the Save_as_JPEG controls could appear on the image window (inspired by the Firefox find bar) to further cut down on window juggling.

There's quite a number of ways it could be organized, my mockup shows just one:

http://thorwil.affenbande.org/wp-content/uploads/2007/02/ save_as_jpg_integrated_01.jpg

I just had a quick look. Later in the expert evaluation we will get to the save for web scenarios and I will be in a better position to deal with this. But for now:

If we try to do an all in one, then the result has to look and feel like a dialog, not like a main window, because of the modal nature (finish this first) of the task.

It is difficult for me to say whether sawing off more main window bits (no menu bar, tools, palettes, inspectors or rulers; default to magnification tool) and adding more dialog-ness (get buttons out of the status bar) to what you have drawn, or start from scratch on a BIG-preview dialog would be the better way to go.

Advanced options hide 'under' the expander. There could be a button to bring them up in a dialog instead.

My gut feeling says that there is a better solution available here, but I am only able to work on that after the expert evaluation.

File size can be read in the statusbar.

Better keep the quality slider and file size (main cause and effect) physically together.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Thorsten Wilms wrote:

If we try to do an all in one, then the result has to look and feel like a dialog, not like a main window, because of the modal nature (finish this first) of the task.

But this would not be like your common dialog that disappears after Cancel/OK, but rather a window that changes state.

I have nothing against the idea of reusing the main window, but as said, because the task is modal by nature, the UI UI has to reflect that with dialogness. It is simply a UI law of nature.

That means big changes to the main window, as quoted right below:.

It is difficult for me to say whether sawing off more main window bits (no menu bar, tools, palettes, inspectors or rulers; default to magnification tool) and adding more dialog-ness (get buttons out of the status bar) to what you have drawn, or start from scratch on a BIG-preview dialog would be the better way to go.

I thought about removing at least the menubar but decided against it, as you can still zoom, toggle guides ... Might be better to not allow access to editing options, though.

Toggle guides? There is only one thing to do, and that is set the size vs. apparent quality ratio (with the advanced saving options, I know).

The zoom is taken care of with the zoom tool and the controls in the status bar.

File size can be read in the statusbar.

Better keep the quality slider and file size (main cause and effect) physically together.

I wanted to, at first. Then moved it to save width for small images.

If windows re sized for the menu bar to fit in (quite natural except on the mac) then I am sure we can get the quality slider and the calculated file size in.

BTW, some apps have web export dialogs with side by side panes original/compressed. I found toggling between original/preview in the same view to be superior if you want to spot JPG artifacts. It's important it can happen with a single click.

Yep, well observed...

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Thorsten Wilms writes:

I found toggling between
original/preview in the same view to be superior if you want to spot JPG artifacts.

Me too. The new setup where the preview is a layer in the image dialog (I just updated and saw it) is wonderful. I'd been struggling with focus/raise issues with the old separate-window setup (click on the dialog and it would raise the original image window, hiding the preview window, and even when that didn't happen I was always confusing the two similar looking image windows); using a new layer is a great solution and makes it so much easier to see the effect of the quality settings.

I'll add another vote for hiding the Save as dialog when bringing up the JPEG dialog. I often go to the wrong one of the two dialogs after changing desktops or shuffling windows around to see the preview better. Partly that's because they always pop up widely separated on the screen, rather than placing the second dialog on top of the first (they seem to trigger different window manager placement rules). And the buttons on the dialogs are a bit confusing: they both show active Cancel buttons, but Cancel on the Save As dialog is a no-op.

I wish there were a way around needing two dialogs (needing to click Save two different times in order to save). Seems like there must be a way around that, but I can't think of one. Putting jpeg options and dialog-like buttons into the image window doesn't seem like a better solution: you still need to click just as many times, and it sounds jarring for the familiar image window to temporarily change its UI and act like a dialog.

peter sikking writes:

because the task is modal by nature, the UI UI has to reflect that with dialogness. It is simply a UI law of nature.

Is that an argument for making the two dialogs window modal? They aren't now -- I can go back to the image window and draw on it, or whatever, while the dialogs are up.

Hi,

On Sat, 2007-02-03 at 12:48 +0100, Thorsten Wilms wrote:

I think the Save_Image dialog should just disappear after use, as both Cancel and Help are available on the second dialog and what else would it be good for?

If I remember correctly, it used to serve as a place to show the progress-bar in. But we do that in the image window now. It might make sense to hide the save dialog earlier in the save process. That would be a small change that can easily be done.

Then the Save_as_JPEG controls could appear on the image window (inspired by the Firefox find bar) to further cut down on window juggling.

I am sorry but the JPEG plug-in, like all GIMP plug-ins, lives in a different process and can not add controls to the image window. While there certainly are ways to work around this, I don't think that limitation is going to change anytime soon.

Sven

Hi,

On Sat, 2007-02-03 at 11:28 -0800, Akkana Peck wrote:

Me too. The new setup where the preview is a layer in the image dialog (I just updated and saw it) is wonderful. I'd been struggling with focus/raise issues with the old separate-window setup (click on the dialog and it would raise the original image window, hiding the preview window, and even when that didn't happen I was always confusing the two similar looking image windows); using a new layer is a great solution and makes it so much easier to see the effect of the quality settings.

Nothing is new to that. The JPEG plug-in has always behaved that way, if, and only if, you are not using the Export functionality. The way Export is currently implemented, a duplicate of the image is created. This duplicate then has the layers merged and whatever operation is needed to prepare the image for saving. The JPEG plug-in then creates the preview layer on the export image. And it needs creates a display for it. That's what you call the Preview window.

Two things to learn from this:

- Save/Export urgently needs a redesign. Both technically and from a user interface point of view. It probably makes sense to start looking at it from a user's point of view first and then check how such behaviour can be implemented.

- The preview on the image window as currently implemented by the JPEG plug-in is a disastrous hack that has never worked well.

Sven

Hi,

On Sat, 2007-02-03 at 14:02 +0100, peter sikking wrote:

Thorsten Wilms wrote:

I think the Save_Image dialog should just disappear after use, as both Cancel and Help are available on the second dialog and what else would it be good for?

Yeah it can go. It would only make sense if a Cancel on the jpeg options would get you back to the Save_Image dialog, in case you see that the jpeg compression is not appropriate, you change your mind and go back for png or so...

That is the idea. The fact that this doesn't happen currently is just a bug. We will try to fix it.

Sven

Hi,

On Mon, 2007-02-05 at 21:01 +0100, Sven Neumann wrote:

Yeah it can go. It would only make sense if a Cancel on the jpeg options would get you back to the Save_Image dialog, in case you see that the jpeg compression is not appropriate, you change your mind and go back for png or so...

That is the idea. The fact that this doesn't happen currently is just a bug. We will try to fix it.

This is now fixed in trunk. I am afraid that this doesn't improve the situation for the JPEG save dialog though as this means that the Save file-chooser dialog will stay. But the main problem here is that the JPEG plug-in does the wrong thing. The preview in the image window has never worked well and it has caused so many problems already. We should IMO change the JPEG save plug-in instead of working around the problems that are caused by its brokeness.

I hope that we can address this with the Save/Export overhaul that is long due. But we still need a good concept that covers all this.

Sven

On 2/3/07, peter sikking wrote:

Thorsten Wilms wrote:

BTW, some apps have web export dialogs with side by side panes original/compressed. I found toggling between original/preview in the same view to be superior if you want to spot JPG artifacts. It's important it can happen with a single click.

Yep, well observed...

Hi,

I've worked on a similar plug-in. It would be very interesting to hear some comments on it as I am planning to improve it. Here is a short introduction: http://img300.imageshack.us/img300/6571/saveforwebid4.jpg Peter, could you tell if it fits in save for web scenarios and what could be changed to make it better.

Thanks

Hi,

On Tue, 2007-02-06 at 17:01 +0200, Aurimas Juška wrote:

I've worked on a similar plug-in. It would be very interesting to hear some comments on it as I am planning to improve it. Here is a short introduction: http://img300.imageshack.us/img300/6571/saveforwebid4.jpg Peter, could you tell if it fits in save for web scenarios and what could be changed to make it better.

BTW, does this plug-in use GimpPreview widgets? I would like to get some feedback on features and API of GimpPreview and its derivatives.

Sven

Aurimas wrote:

I've worked on a similar plug-in. It would be very interesting to hear some comments on it as I am planning to improve it. Here is a short introduction: http://img300.imageshack.us/img300/6571/ saveforwebid4.jpg
Peter, could you tell if it fits in save for web scenarios and what could be changed to make it better.

I can tell you that in a couple of weeks when we have evaluated our way through the web scenarios. Then I have build up a better understanding of the task and discussed it through.

Nevertheless, - that in-dialog cropping looks like a very uncomfortable way to do that to me;
- the file size should be always displayed very near the quality slider (cause and effect);
- simply display the Size in the fields that are now called Resize now without the open/close triangle, and remove the other size display;
- why can't the plug-in figure out which combination of Optimise/Progressive/Baseline will produce the smallest file size, and let me select that as Smallest? - where is that nifty GIMP quick navigation widget in the corner of the scroll bars?

BTW, some apps have web export dialogs with side by side panes original/compressed. I found toggling between original/preview in the same view to be superior if you want to spot JPG artifacts. It's important it can happen with a single click.

Yep, well observed...

You see, I am already changing my mind here what is the essence of the image preview. It is not original pic vs. compressed jpg, it is compressed jpg vs. file size. The compressed jpg stands on its own. The pristine original pic is not going to be there to compare with, when the jpg is placed at its destination (the website). The central question for the user is 'what am I going to get away with?' The answer to that depends on a dozen factors which all have to be assessed via the users internal value system to get to a decision.

So I think, right now, that the all the image area should be used to preview the jpg, with a Preview checkbox, for the users like Thorsten who want to do original/jpg comparisons.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 2/6/07, peter sikking wrote:

So I think, right now, that the all the image area should be used to preview the jpg, with a Preview checkbox, for the users like Thorsten who want to do original/jpg comparisons.

While we are discussing it, is it possible to add a remark to the current dialog that enabling preview also calculates size of resulted file? I already heard several times from new users that GIMP doesn't calculate resulted JPEG files size at all. This is a tiny change and it I believe that it can make it's way to 2.4

Alexandre

Hi,

On Wed, 2007-02-07 at 05:39 +0300, Alexandre Prokoudine wrote:

While we are discussing it, is it possible to add a remark to the current dialog that enabling preview also calculates size of resulted file? I already heard several times from new users that GIMP doesn't calculate resulted JPEG files size at all. This is a tiny change and it I believe that it can make it's way to 2.4

There's a tooltip on the file-size label for exactly this purpose.

Sven

On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote:

- that in-dialog cropping looks like a very uncomfortable way to do that to me;
- simply display the Size in the fields that are now called Resize now without the open/close triangle, and remove the other size display;

I actually find resize/crop controls redundant in the Save for Web dialog - I usually prepare the image beforehand while keeping it in a native (lossless) format, then just expect to use Save for Web to export the image for upload to a website without touching the original.

Instead, I'd want to see the colour subsampling setting in the export plugin - some images just can't be made good looking with 2x2 colour subsampling.

- why can't the plug-in figure out which combination of Optimise/Progressive/Baseline will produce the smallest file size, and let me select that as Smallest?

Except for Optimize, these settings aren't directly related to file size (although using Progressive encoding usually does lower the image size a bit).

Progressive just changes the way image is stored, and how browser displays it over a slow link. However, with Internet Explorer browser, progressively encoded images load exactly the opposite way you'd expect - nothing will be displayed until whole image is downloaded, then the image appears all at once.

Baseline makes the JPEG file more compatible while sacrificing quality/increasing file size.

Hi,

On 2/6/07, Sven Neumann wrote:

BTW, does this plug-in use GimpPreview widgets? I would like to get some feedback on features and API of GimpPreview and its derivatives.

It actually uses GtkDrawingArea. This is related to zoom & cropping functionality. If we dropped cropping, one of Gimp widgets could be used. Is there any widget which supports - zoom in & out
- GIMP quick navigation widget in the corner of the scroll bars - access to cursor coordinates to give extra control with mouse?

Thanks

Hi,

On 2/7/07, jernej@ena.si wrote:

On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote:

- that in-dialog cropping looks like a very uncomfortable way to do that to me;
- simply display the Size in the fields that are now called Resize now without the open/close triangle, and remove the other size display;

I actually find resize/crop controls redundant in the Save for Web dialog - I usually prepare the image beforehand while keeping it in a native (lossless) format, then just expect to use Save for Web to export the image for upload to a website without touching the original.

The idea is based one of bug list's enhancment request which asks to save image for Internet, ie user wants image to be as small as possible (for example to send with mail or put to forum) and some parts could be cropped and picture could be resized until wanted file size is reached.
It was then decided that this functionality should be put in save for web plug-in. (see http://bugzilla.gnome.org/show_bug.cgi?id=317100 ) Maybe we should discuss again if this functionality is needed and if so, is it convenient to integrate it into save for web plug-in.

Thanks.

On Wed, 07 Feb 2007 11:16:33 +0100, wrote:

On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote:

- that in-dialog cropping looks like a very uncomfortable way to do that to me;
- simply display the Size in the fields that are now called Resize now without the open/close triangle, and remove the other size display;

I actually find resize/crop controls redundant in the Save for Web dialog -
I usually prepare the image beforehand while keeping it in a native (lossless) format, then just expect to use Save for Web to export the image
for upload to a website without touching the original. Instead, I'd want to see the colour subsampling setting in the export plugin
- some images just can't be made good looking with 2x2 colour subsampling.

- why can't the plug-in figure out which combination of Optimise/Progressive/Baseline will produce the smallest file size, and let me select that as Smallest?

Despite the idiot-user title of this feature (copied for PS it seems) there is no magic optimum or true minimum size. All this depends on the nature of the image and quality compromises one is prepared to accept. This is necessarily subjective and can never be predetermined by software.

If the user is so lame that they are going to click on a feature called "save for the web" I sincerly think the most useful way to help him fullfil his needs would be to display a dlg with a brief guide to the key tasks required: cropping , image file format choice, quality/size play-offs etc. Perferably with links to fuller information.

The necessary tools are already in Gimp so why duplicate them? Someone choosing "save for the web" needs help, let's provide some rather than maintaining them in thier ignoracen and providing enevitably compromised solutions.

gg

On Wed, 07 Feb 2007 14:32:04 +0100, Thorsten Wilms wrote:

On Wed, Feb 07, 2007 at 01:58:21PM +0100, gg@catking.net wrote:

Despite the idiot-user title of this feature (copied for PS it seems)

...

If the user is so lame that they are going to click on a feature called "save for the web"

If a user wants to save images for use on the web, save_for_the_web is high level thinking and not lame or idiotic.

I said idiot-user title, it is that sort of title that is treating the user as an idiot.

I should probably have chosen a more precise and less emotive term than lame. In chosing "save for the web" the use indicates he does not know what is involved and is expecting gimp to magically do it for him, not unreasonably since the program is offering that as an option. I believe offering that option to be a mistake. It seems to be mainly motivated by "Photoshop does it so we ought to as well".

The choice of format is secondary. 1. save for web
2. use most appropiate format

Someone
choosing "save for the web" needs help, let's provide some rather than maintaining them in thier ignoracen and providing enevitably compromised solutions.

I know the characteristics of JPG, PNG, GIF. I can usually tell what will work best. There are border cases, though. Then I have to experiment and can't formulate save_as_jpg or save_as_my_png as my initial goal at all.

Well if you can tell what usually works best that probably means you'll slightly better than a "save for the web" feature anyway. You'll probably be able to set an appropriate jpeg compression level for your specific image based on the quality your require for your context.

In other cases, where you need to experiment, you clearly indicate you know what you're doing and my comments dont apply to you.

What I am suggesting is empowering users to get to that stage rather than providing mediocre results with "optimisations" determined without established criteria or prior knowlege of the data.

We have the choice to provide a better solution than PS rather than just playing catch-up.

That's what I'd like to see.

gg

On 2/7/07, gg wrote:

I should probably have chosen a more precise and less emotive term than lame. In chosing "save for the web" the use indicates he does not know what is involved and is expecting gimp to magically do it for him, not unreasonably since the program is offering that as an option. I believe offering that option to be a mistake. It seems to be mainly motivated by "Photoshop does it so we ought to as well".

When you save JPEGs, generally you do it either for web-gallery, or for print, or for display (to be used as wallpaper or something).

Peter might correct me, but "Save for Web" implies doing a tradeoff between quality and file size, whereas neither print nor display destinations require that.

Thus "Save for Web" is a plug-in that deals with a specialized usecase. That's it.

Alexandre

Aurimas Juška writes:

The idea is based one of bug list's enhancment request which asks to save image for Internet, ie user wants image to be as small as possible (for example to send with mail or put to forum) and some parts could be cropped and picture could be resized until wanted file size is reached.

I'd love to see this integrated into the crop tool somehow, rather than hidden off in a "save for web" plug-in. When I crop to a fixed size it's usually not for the web -- I more likely want a desktop background image, or a slide background, or a print.

Crop's Aspect Ratio got a lot easier to manage in 2.3 as opposed to 2.2. So "crop to a fixed aspect ratio, then rescale" is much easier now -- presuming you understand aspect ratio and don't mind typing two colon- separated numbers. (Though I haven't figured out the "" and "Set" buttons, which have no tooltips and don't seem to do anything, or why you'd want a 1:1 preset button but not presets for 4:3 or 4:6 or "Keep image's aspect ratio").

But I can certainly understand why so many users want Crop+Scale all in one step. It's a very common operation, and it would be a shame to offer it, then cripple it by putting it in a plug-in where the crop has to happen in a small preview area.

On Wed, 07 Feb 2007 19:50:53 +0100, Akkana Peck wrote:

But I can certainly understand why so many users want Crop+Scale all in one step. It's a very common operation, and it would be a shame to offer it, then cripple it by putting it in a plug-in where the crop has to happen in a small preview area.

yes, this makes a lot of sense. Association of crop and scale has no relation to the final image file format.

I always work in a lossless format until all cropping scaling and other data processing is done, so I would be very unlikely to associate either of these actions with a save as jpeg operation.

gg

On 2/7/07, Sven Neumann wrote:

Hi,

On Wed, 2007-02-07 at 05:39 +0300, Alexandre Prokoudine wrote:

While we are discussing it, is it possible to add a remark to the current dialog that enabling preview also calculates size of resulted file? I already heard several times from new users that GIMP doesn't calculate resulted JPEG files size at all. This is a tiny change and it I believe that it can make it's way to 2.4

There's a tooltip on the file-size label for exactly this purpose.

As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled in preferences.

Alexandre

Hi,

On Wed, 2007-02-07 at 10:50 -0800, Akkana Peck wrote:

Crop's Aspect Ratio got a lot easier to manage in 2.3 as opposed to 2.2. So "crop to a fixed aspect ratio, then rescale" is much easier now -- presuming you understand aspect ratio and don't mind typing two colon- separated numbers. (Though I haven't figured out the "" and "Set" buttons, which have no tooltips and don't seem to do anything, or why you'd want a 1:1 preset button but not presets for 4:3 or 4:6 or "Keep image's aspect ratio").

If you had read the specification (and I expect all of you to have done that), you would know that the current state of the rectangle tool options panel is far from final. I plan to devote some time to it soon so that hopefully it will look and feel a lot better with the next development release.

Sven

Hi,

On Thu, 2007-02-08 at 02:36 +0300, Alexandre Prokoudine wrote:

As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled in preferences.

There is. I just checked once more (and I had already checked yesterday).

Sven

Hi,

On Wed, 2007-02-07 at 13:13 +0200, Aurimas Juška wrote:

It actually uses GtkDrawingArea. This is related to zoom & cropping functionality. If we dropped cropping, one of Gimp widgets could be used.

I don't see why you couldn't implement cropping with one of the GimpPreview widgets.

Is there any widget which supports - zoom in & out
- GIMP quick navigation widget in the corner of the scroll bars - access to cursor coordinates to give extra control with mouse?

GimpZoomPreview

Sven

On 2/8/07, Sven Neumann wrote:

As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled in preferences.

There is. I just checked once more (and I had already checked yesterday).

What I was trying to tell you is that that message exists, but doesn't show up. Which means that something is broken ;-)

Alexandre

Hi,

On Thu, 2007-02-08 at 10:41 +0300, Alexandre Prokoudine wrote:

What I was trying to tell you is that that message exists, but doesn't show up. Which means that something is broken ;-)

It does show up. So the brokeness seems to be on your setup.

Sven

On 2/8/07, Sven Neumann wrote:

What I was trying to tell you is that that message exists, but doesn't show up. Which means that something is broken ;-)

It does show up. So the brokeness seems to be on your setup.

Both Ubuntu Feisty laptop at home and WinXP SP2 workstation at work? ;-)

My guess is that it's locale related. Could somebody else with non EN locale check if it works please?

Alexandre

Sven Neumann writes:

If you had read the specification (and I expect all of you to have done that), you would know that the current state of the rectangle tool options panel is far from final.

I knew it wasn't final. I did wonder what the current buttons were for.

The specification you're referring to is the one Peter posted to this list in December? In other words, http://lists.xcf.berkeley.edu/lists/gimp-developer/2006-December/016890.html (The image attachment didn't make it to the archives, but I saved the message and it's not that different from the current aspect ratio, except that it has portrait and landscape buttons to the right of the text field instead of the mysterious "Fix".)

I'm confused about one thing in the spec: it says | From all three tool option panels, remove all the Fix buttons, | The line with the Aspect fields, and the three buttons below it.

Just to be clear, the line with the Aspect fields isn't really removed, just changed to look like Peter's sketch, right? So the text field stays, a "Use ratio" checkbox is added above it, and the Fix to its right are replaced with the portrait/landscape icons.

I'd be happy to update the tool options to be more like the spec, if you're looking for a volunteer and it wouldn't step on any toes.