The screenshot delay behaves exactly as I have always expected it to. If you select immediately and then wait 5 seconds, how do you change virtual desktops to get to the window in question without 'accidentally' selecting your pager? Then again, I have often desired a feature do what you propose here. I think both options should be available, in combination, in the form of two delays. One before selecting the window, and one before taking the screenshot.

On 1/27/07, Steve Stavropoulos wrote:

I found myself today in the need to take a screenshot of a window with an open menu. I selected Acquire->Screenshot in gimp and in the dialog I chose a delay of 5 seconds, to give me time to open the menu after I selected the window to grab. But, after a while I figured out that gimp first waits for the 5 seconds to pass and then gives you the chance to select the window. That is the exact opposite of what I expected and didn't allow me to take the screenshot of the open menu I wanted. Maybe if I had selected to take a screenshot of the entire screen I would have been able to do my job, but I wrote the patch in the end of the message quicker. My ultra small patch just selects the window _first_ and grabs after applying the delay. To summarize, I think the current behaviour of screenshot.c is the opposite of what a user expects, has no practical value I can think of and in use cases as mine has dramatic impact in usability. Of course, there is a possibility that I miss something and that is why I send this patch here, so we can talk about what is "right" and "wrong".

Index: screenshot.c =================================================================== --- screenshot.c (revision 21691) +++ screenshot.c (working copy) @@ -328,9 +328,6 @@

if (status == GIMP_PDB_SUCCESS) {
- if (shootvals.select_delay > 0) - shoot_delay (shootvals.select_delay); -
if (shootvals.shoot_type != SHOOT_ROOT && ! shootvals.window_id) {
shootvals.window_id = select_window (screen); @@ -342,6 +339,9 @@

if (status == GIMP_PDB_SUCCESS) {
+ if (shootvals.select_delay > 0) + shoot_delay (shootvals.select_delay); +
image_ID = shoot (screen);

if (image_ID == -1)

On 1/27/07, Steve Stavropoulos wrote:

I chose a delay of 5 seconds, to give me time to open the menu after I selected the window to grab. But, after a while I figured out that gimp first waits for the 5 seconds to pass and then gives you the chance to select the window. That is the exact opposite of what I expected and didn't allow me to take the screenshot of the open menu I

Clarence Risher writes:

The screenshot delay behaves exactly as I have always expected it to. [ ... ] Then again, I have often desired a feature do what you propose here. I think both options should be available, in combination, in the form of two delays.

In gimp 2.2, the screenshot dialog offered both options. Early on in 2.3, the before-selection delay disappeared leaving only the before-grab delay. But apparently there's been some in-fighting between the people who want one delay vs. the other, and in current CVS the winner is the before-selection delay, which unfortunately leaves no way of grabbing a single window while doing something in it (like popping up a menu). Bummer! I personally found the before- grab delay very useful, but never need the before-selection delay.

An svn log of screenshot.c shows the sequence:

------------------------------------------------------------------------ r20867 | neo | 2006-09-17 05:21:09 -0700 (Sun, 17 Sep 2006) | 6 lines

2006-09-17 Sven Neumann

* plug-ins/common/screenshot.c: reverted Bill's change. Applying the delay before the selection makes as much sense as doing it afterwards. Do it consistently at least.

------------------------------------------------------------------------ r20862 | weskaggs | 2006-09-15 09:11:36 -0700 (Fri, 15 Sep 2006) | 5 lines

Bill Skaggs

* plug-ins/common/screenshot.c: when shooting a region, apply delay _after_ selecting region, applying before is useless.

------------------------------------------------------------------------ r20121 | mitch | 2006-06-18 02:44:43 -0700 (Sun, 18 Jun 2006) | 6 lines

2006-06-18 Michael Natterer

* plug-ins/common/screenshot.c: apply the delay before selecting, not before grabbing, so the user has time to rearrange things. Fixes bug #345214.

Bugzilla isn't responding right now so I can't review bug 345214, but it sounds like there's a good argument for going back to offering both delays, like 2.2 did. There are good reasons for both. Sven, Bill, Mitch? Any chance of that?

Meanwhile: you can still grab a menu by shooting the entire screen with a delay, then cropping it afterward ... arduous but better than nothing. Or use 2.2. :-)

On 1/28/07, Akkana Peck wrote:

Meanwhile: you can still grab a menu by shooting the entire screen with a delay, then cropping it afterward ... arduous but better than nothing. Or use 2.2. :-)

With a fairly simple plugin, it would be easy to auto crop -- just click on the window, the plugin finds out the location and extents of the window, and does the cropping.

On Sun, 28 Jan 2007 04:49:12 +0100, Akkana Peck wrote:

On 1/27/07, Steve Stavropoulos wrote:

I chose a delay of 5 seconds, to give me time to open the menu after I selected the window to grab. But, after a while I figured out that gimp first waits for the 5 seconds to pass and then gives you the chance to select the window. That is the exact opposite of what I expected and didn't allow me to take the screenshot of the open menu I

Clarence Risher writes:

The screenshot delay behaves exactly as I have always expected it to. [ ... ] Then again, I have often desired a feature do what you propose here. I think both options should be available, in combination, in the form of two delays.

In gimp 2.2, the screenshot dialog offered both options. Early on in 2.3, the before-selection delay disappeared leaving only the before-grab delay. But apparently there's been some in-fighting between the people who want one delay vs. the other, and in current CVS the winner is the before-selection delay, which unfortunately leaves no way of grabbing a single window while doing something in it (like popping up a menu). Bummer! I personally found the before- grab delay very useful, but never need the before-selection delay.

An svn log of screenshot.c shows the sequence:

------------------------------------------------------------------------ r20867 | neo | 2006-09-17 05:21:09 -0700 (Sun, 17 Sep 2006) | 6 lines

2006-09-17 Sven Neumann

* plug-ins/common/screenshot.c: reverted Bill's change. Applying the delay before the selection makes as much sense as doing it afterwards. Do it consistently at least.

------------------------------------------------------------------------ r20862 | weskaggs | 2006-09-15 09:11:36 -0700 (Fri, 15 Sep 2006) | 5 lines

Bill Skaggs

* plug-ins/common/screenshot.c: when shooting a region, apply delay
_after_ selecting region, applying before is useless.

------------------------------------------------------------------------ r20121 | mitch | 2006-06-18 02:44:43 -0700 (Sun, 18 Jun 2006) | 6 lines

2006-06-18 Michael Natterer

* plug-ins/common/screenshot.c: apply the delay before selecting, not before grabbing, so the user has time to rearrange things. Fixes bug #345214.

Bugzilla isn't responding right now so I can't review bug 345214, but it sounds like there's a good argument for going back to offering both delays, like 2.2 did. There are good reasons for both. Sven, Bill, Mitch? Any chance of that?

Meanwhile: you can still grab a menu by shooting the entire screen with a delay, then cropping it afterward ... arduous but better than nothing. Or use 2.2. :-)

Yes, this sort of feature regression is regrettable. Things should work the same or better after an "upgrade", not become less useful.

Clearly the two functions are not the same. If Bill's workaround to the feature loss is deemed inconsistant then clearly it should be reverted to 2.2 behaviour.

What was the reason for this being removed?

gg

Hi,

In gimp 2.2, the screenshot dialog offered both options. Early on in 2.3, the before-selection delay disappeared leaving only the before-grab delay. But apparently there's been some in-fighting between the people who want one delay vs. the other, and in current CVS the winner is the before-selection delay, which unfortunately leaves no way of grabbing a single window while doing something in it (like popping up a menu).

You can still grab the whole screen if you need to take a screenshot with a popup menu. After all the popup menu is a different window anyway. So it seems strange to use the "Single Window" option for this. And it also won't work correctly if your popup menu extended the window it is popping up from.

Sven

On 1/28/07, Steve Stavropoulos wrote:

The only use of "delay before selecting" I have heard so far is to change desktops before grabbing, but for me the "logical" thing to do in that case would be to move the screenshot plugin to the desktop I wanted and take the screenshot then. Is there any other use of "delay before selecting"? Why should we keep it? Even if you don't like my proposal, I think it would be better if you removed the delay functionality completely.

Delay before selecting gives you more control over precisely what is captured, since it happens at the moment you click, where the state of the window might change in some cases when using delay after selecting.

Also, what if the window in question cannot be put into the proper state until after the delay starts? A full screen app/game that cannot be (de)focused, for instance. I have, on rare occasions, encountered this need, where I have to apply a delay before selecting and use that delay to actually start the program to be the target of the screenshot.

Hi,

perhaps we should remove the screenshot plug-in altogether. The functionality doesn't really belong into an image manipulation program. Since there doesn't seem to be a platform-agnostic way of taking screenshots, perhaps we should leave it up to the operating system. As long as people can easily import the screenshot into GIMP, that should be sufficient.

Sven

On Sun, Jan 28, 2007 at 02:05:54PM +0100, Sven Neumann wrote:

Hi,

perhaps we should remove the screenshot plug-in altogether. The functionality doesn't really belong into an image manipulation program. Since there doesn't seem to be a platform-agnostic way of taking screenshots, perhaps we should leave it up to the operating system. As long as people can easily import the screenshot into GIMP, that should be sufficient.

Please leave it in.

It's the only means of taking a screenshot that just works here. It has options that make it easy to shoot a single window. Every single screenshot I take ends up in GIMP anyway (and I assume it's the same for most users)

-- Thorsten Wilms

Hi,

I don't think the plug-in will be removed but I would like not to clutter the user interface again. The current UI seems to be more appealing and usable than what we used to have.

Personally I tend to use the Screenshot functionality that is built into the GNOME desktop. The screenshot is just a keypress (Print, Alt-Print) away and importing it into GIMP is accomplished easily by dragging the preview onto the GIMP toolbox.

Sven

Sven Neumann writes:

I don't think the plug-in will be removed but I would like not to clutter the user interface again. The current UI seems to be more appealing and usable than what we used to have.

Okay, it sounds like the developers aren't willing to put back the delay functionality that was removed from the screenshot plug-in.

So for those of us who need the delay and don't want to go back to 2.2, I've grabbed the old 2.2 screenshot plug-in, updated it so it works with 2.3, fixed a couple of warnings it was giving (gchar vs. guchar), and made it build as a standalone plug-in (with gimptool --install). You can get it at: http://shallowsky.com/software/gimp/sscreenshot.c

I gave it the lame name "Super Screen Shot" so it wouldn't conflict with the existing screenshot plug-in (for one thing, it doesn't do the nice "grab a region of the screen" function that the 2.3 plug-in does, though I may add that at some point).

One caveat: On Ubuntu Edgy, I find that neither sscreenshot nor the old 2.2 screenshot actually grab menus any more. Something has changed in the Xorg setup, or maybe gtk stopped doing saveunders, or something? and I just get garbage where the menu should be. I haven't yet had a chance to look into exactly what's different, but in the mean time, delayed screenshots should work on any distro where 2.2 worked.

Hi,

On Mon, 2007-01-29 at 22:21 -0800, Akkana Peck wrote:

Okay, it sounds like the developers aren't willing to put back the delay functionality that was removed from the screenshot plug-in.

So for those of us who need the delay and don't want to go back to 2.2, I've grabbed the old 2.2 screenshot plug-in, updated it so it works with 2.3, fixed a couple of warnings it was giving (gchar vs. guchar), and made it build as a standalone plug-in (with gimptool --install).

Why don't you just copy the screenshot binary from the 2.2 installation to your gimp-2.3 installation?

Also your approach is very lame indeed. This discussion wasn't even close to coming to an end. It would have been a lot nicer to propose a solution instead of wasting time like this. So far no one has even tried to propose a user interface that fits all needs.

Sven

On 1/30/07, Sven Neumann wrote:

to propose a user interface that fits all needs.

imho, the 2.2 interface met all needs. i have yet to hear any reason for eliminating either option, other than removing ONE element from the screenshot GUI.

(sorry for the dupe email Sven)

Hi,

On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote:

On 1/30/07, Sven Neumann wrote:

to propose a user interface that fits all needs.

imho, the 2.2 interface met all needs. i have yet to hear any reason for eliminating either option, other than removing ONE element from the screenshot GUI.

We have had several reports about this UI being confusing. Users filed bug reports claiming that the plug-in wouldn't do the right thing. Obviously they did not understand the user interface. And that is not surprising because it is quite irritating. Just try the user interface on your grandmother.

Now someone please show some creativity. Asking for the changes to be reverted is a punch in the face of the people that have put their free time into improving the usability of this plug-in.

Sven

On 1/30/07, Sven Neumann wrote:

On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote:

On 1/30/07, Sven Neumann wrote:

to propose a user interface that fits all needs.

imho, the 2.2 interface met all needs. i have yet to hear any reason for eliminating either option, other than removing ONE element from the screenshot GUI.

We have had several reports about this UI being confusing. Users filed bug reports claiming that the plug-in wouldn't do the right thing. Obviously they did not understand the user interface. And that is not surprising because it is quite irritating. Just try the user interface on your grandmother.

Now someone please show some creativity. Asking for the changes to be reverted is a punch in the face of the people that have put their free time into improving the usability of this plug-in.

Well then, as crude as it may sound, consider this an intentional punch in the face, as much so as those people punched Ms Peck (great book, btw) in the face by making her waste time un-crippling the plugin. As soon as someone integrates the region feature into the 2.2 plugin, I will be running that. As has been mentioned in so many other threads time and again, you can't hold GIMP out as a viable replacement for Photoshop AND make it grandmother-friendly. The 2.2 interface was fine. Maybe it needs better tooltips and labels for some people. Hide one of the delays in an 'advanced options' panel if you must. But do not remove functionality just to make grandma happy. Removing functionality is never the answer. Removing functionality is the question. The answer is NO.

Clarence, would it be better to be not so aggressive? ;)

Sven Neumann (sven@gimp.org) wrote:

Also your approach is very lame indeed. This discussion wasn't even close to coming to an end. It would have been a lot nicer to propose a solution instead of wasting time like this.

Please realize that your mails sound very much like you dont really want to change anything. You nearly suggested removing the screenshot plugin, you think of the current UI to be more appealing, you suggest various workarounds. None of your mails up to Akkanas latest mails even suggests that you are willing to reopen this issue.

Now you are demeaning akkanas IMHO valid approach which is IMHO not fair. Fortunately you finally seem to open up a little regarding a discussion of the UI. But I'd really appreciate if you'd value other peoples work as much as you expect your own work to be valued.

Bye, Simon

From: Sven Neumann
Date: Tue, 30 Jan 2007 09:35:17 +0100

On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote: > On 1/30/07, Sven Neumann wrote: > > to propose a user interface that fits all needs. >
> imho, the 2.2 interface met all needs. i have yet to hear any > reason for eliminating either option, other than removing ONE > element from the screenshot GUI.

We have had several reports about this UI being confusing. Users filed bug reports claiming that the plug-in wouldn't do the right thing. Obviously they did not understand the user interface. And that is not surprising because it is quite irritating. Just try the user interface on your grandmother.

Now someone please show some creativity. Asking for the changes to be reverted is a punch in the face of the people that have put their free time into improving the usability of this plug-in.

If those people choose to take it that way. Another way to interpret it is that the experiment was tried, but failed.

IMHO the criterion that all functionality should be easy and obvious for a naive user is misplaced, particularly when it's taken to the extreme of "we shouldn't have any functionality that isn't easy and obvious for a naive user". There are a lot of interesting things that aren't easy or obvious to people who don't have the context, and sometimes that context is by its nature quite extensive. To say that we shouldn't do these things because innocent users might stumble across them and get confused is to permanently doom ourselves to having very limited functionality. I'm well aware that I tend toward the opposite extreme, but even with Gutenprint I have people asking for more tunables because they have no other way of doing what they want (these are OS X users -- largely professional photographers, I think -- who want very fine grained control over the ink generation).

I understand that no project has time to implement every single feature demanded by every single user, and that feature bloat carries maintenance costs. That argument doesn't apply to this situation -- this isn't a newly-added feature; it was a conscious decision to remove something (in a plugin, not in the core application) that was already there and working. If the interface is confusing, then maybe it's a reason to improve it; maybe something as simple as improving the help message would serve the purpose.

The two options really serve two entirely different purposes; it may inherently be impossible to combine them into one that works for everyone.

For my part, I've been awfully tempted to port the GTK 1.2 file load and save dialogs forward to GTK 2.x. I suspect that my limited time is better spent on Gutenprint and perhaps KPhotoAlbum, but those dialogs are simply very painful to use.

On Tuesday, January 30, 2007, 9:35:17, Sven Neumann wrote:

We have had several reports about this UI being confusing. Users filed bug reports claiming that the plug-in wouldn't do the right thing. Obviously they did not understand the user interface. And that is not surprising because it is quite irritating. Just try the user interface on your grandmother.

This is one thing I dislike about GTK+/Gnome in general - "clueless users think XYZ is confusing [because they don't bother to read documentation], so let's remove features until only something basic remains; who cares about advanced users that may have actually needed that feature".

Now someone please show some creativity. Asking for the changes to be reverted is a punch in the face of the people that have put their free time into improving the usability of this plug-in.

How about this: get rid of the delay completely, and instead take the screenshot when a certain key (eg. F12) is pressed?

On 1/30/07, Robert L Krawitz wrote:

For my part, I've been awfully tempted to port the GTK 1.2 file load and save dialogs forward to GTK 2.x. I suspect that my limited time is better spent on Gutenprint and perhaps KPhotoAlbum, but those dialogs are simply very painful to use.

http://prokoudine.info/shots/gimp/gtk-autocomplete.png

With gtk 2.10.x I see no point either porting gtk 1.2 dialog or even discussing it :))

/me ducks

Alexandre

On Tue, Jan 30, 2007 at 01:10:56PM +0100, jernej@ena.si wrote:

How about this: get rid of the delay completely, and instead take the screenshot when a certain key (eg. F12) is pressed?

It could be an answer if:

1) the key is customizable 2) we are really shure that there is no way that another app could stole the keyboard disabling the feature

the first is easy, the second IMHO impossible.

On 1/30/07, Marco Ciampa wrote:

On Tue, Jan 30, 2007 at 01:10:56PM +0100, jernej@ena.si wrote:

How about this: get rid of the delay completely, and instead take the screenshot when a certain key (eg. F12) is pressed?

It could be an answer if:

1) the key is customizable 2) we are really shure that there is no way that another app could stole the keyboard disabling the feature

the first is easy, the second IMHO impossible.

Compiz/Beryl is known to steal a lot of keys, and since those are becoming mainstream for Linux desktop, it will be quite difficult to find new key combinations that won't be stolen. I can speak only for myself, but I never had any issue with delay.

Alexandre

Date: Tue, 30 Jan 2007 15:13:45 +0300 From: "Alexandre Prokoudine"

On 1/30/07, Robert L Krawitz wrote:

> For my part, I've been awfully tempted to port the GTK 1.2 file load > and save dialogs forward to GTK 2.x. I suspect that my limited time > is better spent on Gutenprint and perhaps KPhotoAlbum, but those > dialogs are simply very painful to use.

http://prokoudine.info/shots/gimp/gtk-autocomplete.png

With gtk 2.10.x I see no point either porting gtk 1.2 dialog or even discussing it :))

Could you at least put file modification time (not just date) and size in the information?

Then there's also the problem of the save dialog not showing what directory it's saving into (the folder name isn't very helpful if I have multiple directories with the same name). The path bar on the open dialog is quite useful and would be just as useful on the save dialog.

Well what do you know?

At the moment Kamila and I are very busy with our (interaction architecture) expert evaluation of the current GIMP, and this morning we happen to stop by the screenshot plugin.

We actually took into account all comments made in this thread up to that moment.

Here are our findings:

Absolute number one:

Yes, taking screenshots is a task for the OS/desktop environment. That guarantees that it is available in every app. Also looking at the product vision I do not see screenshots as something essential that GIMP must do.

But the the GIMP team consist of nice guys and girls, so they leave the screenshot feature in. Also OK with us, the interaction architects.

One delay or two?

After looking at the old UI, and the UI in 2.3.13, taking into consideration
- the complexities of taking a snap of a window with a menu flapped open or a button being pushed; - traversing trough virtual desktops; - how window managers treat menus;
- relative obscurity of the use cases; - the stress on ease of remembering (used every once in a while) of this feature;
- the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out).

we are positively sure that the solution shown in 2.3.13 is the better solution. One delay, with one meaning.

We would like to see however two improvements:

1) A big, fat visual countdown of the delay. I can see a big (200 point font) semitransparent numbers overlaying the screen counting down 4-3-2-1. No more guessing how long do we still have to get that other window in front.

2) A better explanation of the delay. Move the delay value spin-box up a line, behind the word Delay, and take some room below it for a two-line sentence that confirms what will happen next. Use 3 different texts, one for each of the shot modes (window / screen / region), because what you can do with the cursor after the delay is different for each mode.

BTW: we did not take into account the use of GIMP by grandmas, only used-in-anger by hard-boiled 'pros' according to the product vision.

I think that puts an end to any doubts,

--ps

principal user interaction architect man + machine interface works

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

Hi,

On Tue, 2007-01-30 at 11:32 +0100, Simon Budig wrote:

Please realize that your mails sound very much like you dont really want to change anything.

True. I don't think that the requested change should be made. That does however not mean that it cannot be done and will not be done. There has never been any final decision from my part. Everything I say is subject to discussion and I am always open for arguments and willing to change my mind.

In this particular case I do however expect that someone takes the time to evaluate both the 2.2 and the current UI and to check them against common use cases. And if it turns out that we need two delays, then it would have been appropriate to come up with a quick mockup of how such a user interface could look like without reintroducing the problems that we have with the old UI. I don't think that is asked too much.

Sven

Hi,

On Tue, 2007-01-30 at 13:10 +0100, jernej@ena.si wrote:

How about this: get rid of the delay completely, and instead take the screenshot when a certain key (eg. F12) is pressed?

This works nicely but can only be implemented reasonably well on the Desktop level. Actually, it's exactly how the GNOME screenshot utility works. Being able to take a screenshot by using a global keyboard shortcut makes it a lot more useful than the GIMP's screenshot plug-in can ever become.

Sven

Hi,

On Tue, 2007-01-30 at 17:51 +0100, peter sikking wrote:

We would like to see however two improvements:

1) A big, fat visual countdown of the delay. I can see a big (200 point font) semitransparent numbers overlaying the screen counting down 4-3-2-1. No more guessing how long do we still have to get that other window in front.

Unfortunately that is probably not possible to implement in a portable fashion. One thing that I could imagine that might work is to use custom cursors. While the pointer is grabbed, we could let the mouse cursor count down the remaining seconds.

Sven

Sven Neumann writes:
S> Also your approach is very lame indeed. This discussion wasn't even S> close to coming to an end.

It wasn't? I waited more than a day after your last posting, and there was nothing more. I don't think most of us thought that more begging was going to accomplish anything after you said no.

S> It would have been a lot nicer to propose a S> solution instead of wasting time like this. So far no one has even tried S> to propose a user interface that fits all needs.

That's because the old interface was fine for most people. You're playing feature blackmail -- "I'm going to remove this feature in order to force someone to come up with a new UI that I like, except that I may never like any UI enough, in which case you'll have to do without your feature forever." Perhaps you think that's a good motivation to get people working on the UI, but in reality it just makes people frustrated and angry.

And in any case, it looks like there's not much point in anyone else trying to contribute to UI design:

peter sikking writes: P> At the moment Kamila and I are very busy with our (interaction P> architecture) expert evaluation of the current GIMP, and this P> morning we happen to stop by the screenshot plugin. [ ... skip to end of message ... ]
P> I think that puts an end to any doubts,

Oh, well, that's it, then. There's no point in mere users trying to offer any input.

P> - the fact that it is a piece of cake to cut out a rectangle P> out of a image in GIMP, or two added rectangles (window + P> menu sticking out).

Peter, I have to ask: how much have you actually used GIMP for screenshots? Have you done a lot windows cut from full-screen screenshots? Or talked to users who do?

Here's why I care:

For the book, I had to make hundreds of screenshots, many of them showing menus or other transient features such as brush outlines. For some, where the menus were entirely inside the window, I was able to use "single window" with delay. For others, where menus extended outside the window, I had to use "region of the screen" (which also is no longer available, since that too needs the delay) or "full screen", then crop off the part that wasn't window or menu.

It's easy to say "GIMP's good at selecting and cropping", and indeed it is (especially with the new resizable rect select tool). But it turns out that adjusting crop/selection rectangles to pixel precision, so that you get all of the window border and none of the desktop background, is quite a fiddly operation. You're trying to line up the XOR selection boundary with the shadows on the window borders, and it's easy to get one pixel off (e.g. get the XOR line on top of the shadow instead of just outside it) and not realize until later that you have to do it over.

Selecting large regions then cropping is MUCH more work than selecting a single window with decoration.

P> we are positively sure that the solution shown in 2.3.13 P> is the better solution. One delay, with one meaning.

Peter, I couldn't find in your message where you explained why you concluded the pre-selection delay is worthwhile, while the post-selection delay is not. Can you explain that more clearly?

(I like your idea of a countdown window -- that's something I've never seen before in a screenshot app, but it's a good idea!)

Hi,

On Tue, 2007-01-30 at 11:04 -0800, Akkana Peck wrote:

It wasn't? I waited more than a day after your last posting, and there was nothing more. I don't think most of us thought that more begging was going to accomplish anything after you said no.

I never said no. I only explained the changes that happened since 2.2 and explained why I think that the current UI is better. That doesn't mean that it cannot be improved further. It only means that I am unwilling to revert the whole thing.

That's because the old interface was fine for most people. You're playing feature blackmail -- "I'm going to remove this feature in order to force someone to come up with a new UI that I like, except that I may never like any UI enough, in which case you'll have to do without your feature forever." Perhaps you think that's a good motivation to get people working on the UI, but in reality it just makes people frustrated and angry.

Sorry, but UI design is not about like or dislike. All I want is that someone comes up with a UI proposal and shows us how it is better than the current one. At least show us that you actually tried to consider the problems and looked for solutions.

You can't just say that the old user interface was fine and that we should revert to it. That would mean ignoring the many complaints that led to this change.

Sven

Hi,

On Tue, 2007-01-30 at 11:04 -0800, Akkana Peck wrote:

For the book, I had to make hundreds of screenshots, many of them showing menus or other transient features such as brush outlines. For some, where the menus were entirely inside the window, I was able to use "single window" with delay. For others, where menus extended outside the window, I had to use "region of the screen" (which also is no longer available, since that too needs the delay) or "full screen", then crop off the part that wasn't window or menu.

Any particular reason why you didn't use the screenshot feature of your desktop for this? Just asking. Please don't get upset again. I am only trying to get an idea on why you prefer to use the screenshot plug-in for this.

Sven

On Tue, 30 Jan 2007 20:04:31 +0100, Akkana Peck wrote:

[ ... skip to end of message ... ] P> I think that puts an end to any doubts, Oh, well, that's it, then.
There's no point in mere users trying to offer any input.

hmm, when I first read that earlier it sounded uncomfortably like : "I think that puts an end to any arguements".

Peter has come up with some good improvements already and I'm sure there'll be a lot more but I hope he get's it 100% right 'cos I get the feeling there will be no discussion afterwards.

Luckily we still have your lame effort to fall back on when needed.

gg.

On 1/30/07, peter sikking wrote:

- the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out).

For the record, windows are not always rectangular, or do not always fill their bounding box. Or they may contain (alpha) transparent areas that are well nigh uncleanable when full-screen screenshot'd without sufficient prearrangement.

(sorry for the duplicate peter, i always forget this mailing list doesnt set reply-to)

On Tue, Jan 30, 2007 at 08:22:11PM +0100, Sven Neumann wrote:

Any particular reason why you didn't use the screenshot feature of your desktop for this? Just asking.

Not everybody uses a desktop that has a screenshot feature built in. I don't, and whenever I want a screenshot I use the Gimp plugin. I would be very disappointed to see it removed.

Alex Pounds writes:

On Tue, Jan 30, 2007 at 08:22:11PM +0100, Sven Neumann wrote:

Any particular reason why you didn't use the screenshot feature of your desktop for this? Just asking.

Not everybody uses a desktop that has a screenshot feature built in. I don't, and whenever I want a screenshot I use the Gimp plugin. I would be very disappointed to see it removed.

Same here. I have set up a desktop function that does a screenshot via import (from image magick); but that doesn't allow me controls like delays, and it saves to a file which I then have to open in gimp as a separate step (and remember to delete later). I use it for quickie "show someone on bugzilla or IRC what I'm seeing" snaps but not for the important ones.

For what it's worth, every time I see the question "How do I make a screenshot?" posed on a beginner/intermediate Linux list, the answer always ends up being GIMP. It's still the best method that's not dependent on users running specific versions of specific desktops.

On Tue, 30 Jan 2007 20:22:11 +0100, Sven Neumann wrote:

Any particular reason why you didn't use the screenshot feature of your desktop for this? Just asking. Please don't get upset again. I am only trying to get an idea on why you prefer to use the screenshot plug-in for this.

I'm not sure if you're assuming everyone is using gnome here. I work on xfce4 and I dont have a screenshot applet or whatever. I have scrot if I dont use gimp. Most window manager screenshots seems just to grab the whole screen. The nice thing about the gimp one was that it's more specific and precise.

Hi,

On Tue, 2007-01-30 at 14:03 -0600, Clarence Risher wrote:

For the record, windows are not always rectangular, or do not always fill their bounding box. Or they may contain (alpha) transparent areas that are well nigh uncleanable when full-screen screenshot'd without sufficient prearrangement.

The windows are still rectangular, even if they have a bitmask or alpha channel that makes their shape appear non-rectangular. Screenshots of such windows will always be rectangular so this doesn't really matter here.

Sven

On Tue, Jan 30, 2007 at 12:36:54PM -0800, Akkana Peck wrote:

Alex Pounds writes:

On Tue, Jan 30, 2007 at 08:22:11PM +0100, Sven Neumann wrote:

Any particular reason why you didn't use the screenshot feature of your desktop for this? Just asking.

Not everybody uses a desktop that has a screenshot feature built in. I don't, and whenever I want a screenshot I use the Gimp plugin. I would be very disappointed to see it removed.

Same here. I have set up a desktop function that does a screenshot via import (from image magick); but that doesn't allow me controls like delays, and it saves to a file which I then have to open in gimp as a separate step (and remember to delete later). I use it for quickie "show someone on bugzilla or IRC what I'm seeing" snaps but not for the important ones.

For what it's worth, every time I see the question "How do I make a screenshot?" posed on a beginner/intermediate Linux list, the answer always ends up being GIMP. It's still the best method that's not dependent on users running specific versions of specific desktops.

I use alternatively

1) gimp-2.2 2) gimp-2.3
3) ksnapshot

1) when I need the delay that is missing in gimp-2.3 2) or 3) when I want to save time autocropping the window decorations 3) when I cannot use 2) and viceversa (taking gimp-2.3 dialogs snapshots for example or using gimp under MS Windows or ReactOS)

Please do not revert to 2.2. IMHO the gimp-2.3 way is better than the 2.2 version, not the best. See ksnapshot for an example of a better interface.

On Tue, Jan 30, 2007 at 11:58:08PM +0200, Steve Stavropoulos wrote:

On 1/28/07, Steve Stavropoulos wrote:

So it seems both options are needed. What about a checkbox below the delay to select when the delay will be applied?

You may need both delays, so I think a second "wait" line not only makes for a fully functional plugin, but removes the ambiguity as to when the delay is applied. In
http://master.math.upatras.gr/~steve/gimp/

Simple and powerful, I like it!

Hi,

On Tue, 2007-01-30 at 23:58 +0200, Steve Stavropoulos wrote:

You may need both delays, so I think a second "wait" line not only makes for a fully functional plugin, but removes the ambiguity as to when the delay is applied. In
http://master.math.upatras.gr/~steve/gimp/ you can find the patch that adds the second wait and the screenshot of the result (taken with the new screenshot plugin making use of both delays). The patch also corrects the tooltip of the first delay as it was referring to the "delay after select".

Nice. Thank you.

Do the two delays make sense for all three options? When you are doing a screenshot of the full screen, one delay should be sufficient. If we go for two spinbuttons as you suggest, the first spinbutton should probably be set insensitive if full screen is selected. Another option would be to change the lower part of the dialog according to the choice made in the upper part. A GtkNotebook with hidden tabs is probably best suited to implement this without causing the dialog to resize itself.

PS. I know nothing about gtk, so the patch may be not very beautiful, but it works nicely.

You should be able to get away with a single "GtkWidget *spinnner" variable. Also you probably want to set tooltips on both spinbuttons.

Sven

Sven wrote:

We would like to see however two improvements:

1) A big, fat visual countdown of the delay. I can see a big (200 point font) semitransparent numbers overlaying the screen counting down 4-3-2-1. No more guessing how long do we still have to get that other window in front.

Unfortunately that is probably not possible to implement in a portable fashion.

Yeah, only a desktop environment can pull something like that off. Which brings us back to "absolute number one:

Yes, taking screenshots is a task for the OS/desktop environment."

One thing that I could imagine that might work is to use custom cursors. While the pointer is grabbed, we could let the mouse cursor count down the remaining seconds.

The delay has one purpose: to allow the user to get her window/ desktop in order, ready for the shot. Maybe better leave the cursor normal during that.

Akkana Peck wrote:

peter sikking writes:
P> At the moment Kamila and I are very busy with our (interaction P> architecture) expert evaluation of the current GIMP, and this P> morning we happen to stop by the screenshot plugin. [ ... skip to end of message ... ]
P> I think that puts an end to any doubts,

Oh, well, that's it, then. There's no point in mere users trying to offer any input.

input is fine, if you tell me something that makes me doubt about the decision that I have taken, then I will re-evaluate the whole thing, taking into account all old and new input.

P> - the fact that it is a piece of cake to cut out a rectangle P> out of a image in GIMP, or two added rectangles (window + P> menu sticking out).

Peter, I have to ask: how much have you actually used GIMP for screenshots? Have you done a lot windows cut from full-screen screenshots? Or talked to users who do?

I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users, in order to make 1% happy. The decide to make 99% happy in the standard distribution, and the 1% can use the (already released! go open source!) super screenshot plugin, or a load of other ways of getting the job done efficiently.

Peter, I couldn't find in your message where you explained why you concluded the pre-selection delay is worthwhile, while the post-selection delay is not. Can you explain that more clearly?

I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way. Hence the delay. Taking screenshot of something on the screen is a field that is one or two orders of magnitude broader than taking screenshots of transient user interface elements. Combined with other factors (need exactly the window, user sees GIMP actually as the right tool for this job...) we get to my estimate useful at max for 1% of our users.

Clarence Risher wrote:

On 1/30/07, peter sikking wrote:

- the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out).

For the record, windows are not always rectangular, or do not always fill their bounding box.

You see, you had me doubting there, but then Sven wrote:

The windows are still rectangular […]

else I would have given the whole thing a re-think.

Marco Ciampa wrote:

See ksnapshot for an example of a better interface.

So I had a look, one delay, but they also gave me an idea how we can make everybody here happy, without the cost of two delays:

In 'snap window' mode the shot shall be taken:

a) on the first mouse-down after the timer (can be zero) has expired; b) immediately, when a non-zero timer expires AND a mouse-button (left, right [pop-up menu], even middle?) is being held down.

The latter captures menus being open or pushbuttons being down exactly when the timer expires.

So you can set a single timer, go to the app, push open or down whatever needed to be pushed and wait for the delay to expire:

snap.

So this mail has become a running narrative towards a better solution.

I thank everyone for their extra input. It helped us to improve GIMP.

--ps

principal user interaction architect man + machine interface works

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

Hi,

On Wed, 2007-01-31 at 00:53 +0100, peter sikking wrote:

So I had a look, one delay, but they also gave me an idea how we can make everybody here happy, without the cost of two delays:

In 'snap window' mode the shot shall be taken:

a) on the first mouse-down after the timer (can be zero) has expired; b) immediately, when a non-zero timer expires AND a mouse-button (left, right [pop-up menu], even middle?) is being held down.

The latter captures menus being open or pushbuttons being down exactly when the timer expires.

Very nice! I gave a quick shot at an implementation and came up with the following patch:

Index: plug-ins/common/screenshot.c =================================================================== --- plug-ins/common/screenshot.c (revision 21819) +++ plug-ins/common/screenshot.c (working copy) @@ -398,10 +398,16 @@

if (status != GrabSuccess) {
- g_message (_("Error grabbing the pointer")); + gint x, y;
+ guint xmask;

- XFreeCursor (x_dpy, x_cursor); - return 0;
+ XQueryPointer (x_dpy, x_root, &x_root, &x_win, &x, &y, &x, &y, &xmask);
+
+ // FIXME: check window type and walk up the window hierarchy until
+ // we hit a toplevel window +
+ if (x_win == None)
+ g_message (_("Error selecting the window")); }

if (shootvals.shoot_type == SHOOT_REGION) @@ -574,9 +580,11 @@
g_free (keys);
}

- XUngrabPointer (x_dpy, CurrentTime); + if (status == GrabSuccess)
+ XUngrabPointer (x_dpy, CurrentTime);

XFreeCursor (x_dpy, x_cursor); +
if (x_gc != None)
XFreeGC (x_dpy, x_gc);

If you actually try this you will understand why I added a FIXME. If you open a popup menu and keep the mouse button pressed until the timer expires, this code takes a screenshot of the popup menu, not of the window that the popup is created from. This behaviour is correct from a technical point of view (after all popup menus are separate windows). But it's not what the user expects. We will somehow have to special-case this. I posted the patch here in case that someone experienced with XLib programming wants to give this a try.

Sven

On 1/30/07, peter sikking wrote:

Clarence Risher wrote:

On 1/30/07, peter sikking wrote:

- the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out).

For the record, windows are not always rectangular, or do not always fill their bounding box.

You see, you had me doubting there, but then Sven wrote:

The windows are still rectangular [edit to restore context: even if they have a bitmask or alpha channel that makes their shape appear non-rectangular. Screenshots of such windows will always be rectangular so this doesn't really matter here. ]

else I would have given the whole thing a re-think.

Sven's argument is true, but does not address my point. In every case like this the process will be more complex than just shot-clip-done. In cases of non-rectangular areas the clipping will be quite annoying. And in the rare case of alpha transparency it would be impossible to "erase" the parts of the desktop or other windows behind the window you are trying to capture.

Hi,

On Tue, 2007-01-30 at 19:09 -0600, Clarence Risher wrote:

Sven's argument is true, but does not address my point. In every case like this the process will be more complex than just shot-clip-done. In cases of non-rectangular areas the clipping will be quite annoying. And in the rare case of alpha transparency it would be impossible to "erase" the parts of the desktop or other windows behind the window you are trying to capture.

The point is that you are bringing up a completely new topic here. There is currently no support whatsoever for shaped windows or windows with an alpha channel. As long as no one adds such support (which would be extremely complicated to get right on all systems), there is no point in arguing about it.

Sven

Hi,

On Tue, 2007-01-30 at 22:03 +0100, gg@catking.net wrote:

I'm not sure if you're assuming everyone is using gnome here. I work on xfce4 and I dont have a screenshot applet or whatever. I have scrot if I dont use gimp. Most window manager screenshots seems just to grab the whole screen. The nice thing about the gimp one was that it's more specific and precise.

Of course I am not assuming that. But I don't know all the other desktop environments out there and I expected that they more or less all have a reasonably well working way of taking screenshots. After all this is where the functionality belongs.

Perhaps the xfce project should think about adding such a tool. Or simply integrate an existing tool. All that needs to be done is to set up some global keyboard shortcuts. But that's better discussed on the xfce lists, I guess...

Sven

On 1/31/07, Sven Neumann wrote:

Hi,

On Tue, 2007-01-30 at 19:09 -0600, Clarence Risher wrote:

Sven's argument is true, but does not address my point. In every case like this the process will be more complex than just shot-clip-done. In cases of non-rectangular areas the clipping will be quite annoying. And in the rare case of alpha transparency it would be impossible to "erase" the parts of the desktop or other windows behind the window you are trying to capture.

The point is that you are bringing up a completely new topic here. There is currently no support whatsoever for shaped windows or windows with an alpha channel. As long as no one adds such support (which would be extremely complicated to get right on all systems), there is no point in arguing about it.

Perhaps there is no intentional support, but I guarantee you that gimp (as of 2.2, and i expect still in 2.3) takes screenshots of non-rectangular windows just fine. The result is a black rectangle containing the visible shape of the window. For a completely silly example, consider a screenshot of xeyes. Think about how bothersome it would be to manually crop out the window behind the eyes (which are oval) if you had to make do with a desktop screenshot and a crop tool. A less silly example is any window decoration theme with rounded corners, or bits that extrude off the edges.

Also, my silly xeyes idea brings up a point on the primary topic as well... I need a delay before selecting the xeyes window to get to the proper desktop, or bring it to the front, and a delay after selecting it because I dont want it to look crosseyed (for anyone who doesnt know, xeyes is two animated eyeballs that stare at the mouse cursor).

From: Sven Neumann
Date: Wed, 31 Jan 2007 08:38:21 +0100

On Tue, 2007-01-30 at 22:03 +0100, gg@catking.net wrote:

> I'm not sure if you're assuming everyone is using gnome here. I work on > xfce4 and I dont have a screenshot applet or whatever. I have scrot if I > dont use gimp. Most window manager screenshots seems just to grab the > whole screen. The nice thing about the gimp one was that it's more > specific and precise.

Of course I am not assuming that. But I don't know all the other desktop environments out there and I expected that they more or less all have a reasonably well working way of taking screenshots. After all this is where the functionality belongs.

Perhaps the xfce project should think about adding such a tool. Or simply integrate an existing tool. All that needs to be done is to set up some global keyboard shortcuts. But that's better discussed on the xfce lists, I guess...

A lot of people don't run an all-out "desktop environment"; they run a simple window manager (fvwm, ctwm) precisely because they don't want a heavyweight environment weighted down with gadgets. xfce4 is popular because it is much lighter weight than KDE or GNOME.

peter sikking writes:

Peter, I have to ask: how much have you actually used GIMP for screenshots? Have you done a lot windows cut from full-screen screenshots? Or talked to users who do?

I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users,

Not being an interaction architect, I'm still not understanding. How did you arrive at the 99% number? Is that the percentage of users who would be slowed down by seeing both delay options? Or by the previous behavior of having a delay only after selection? What is the corresponding percentage of users who are slowed down by having only a before-selection delay? Are these numbers based on usability testing, or user interviews, or analysis of bugs or public comments, or what?

I'm hoping that, this being an open source project, the methodology involved in this interaction analysis is public and available for everone to see and understand and learn from.

[pre- vs. post- selection delay]

I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way.

To get the screenshot dialog out of the way, you mean? Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time?

To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case).

In 'snap window' mode the shot shall be taken:

a) on the first mouse-down after the timer (can be zero) has expired; b) immediately, when a non-zero timer expires AND a mouse-button (left, right [pop-up menu], even middle?) is being held down.

That takes care of menus, but there transient effects which don't involve a mouse button down. For gimp, examples include the cursor outline of a brush, or the line you get pressing shift in a drawing tool. That's admittedly an uncommon case, but how about the very common case of hover effects in a browser?

I also wonder about discoverability: "Sometimes I have to click on the window after the delay, but sometimes I don't." Will people figure out that having a mouse button already pressed is what makes the difference?

Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior.

On Wed, Jan 31, 2007 at 11:02:20AM -0800, Akkana Peck wrote:

[pre- vs. post- selection delay]

I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way.

To get the screenshot dialog out of the way, you mean? Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time?

Yes. I always reserve a workspace for GIMP, though.

To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case).

In my case, I use a short delay just to switch workspace most of the time. Sometimes I need more delay for some menu or popup.

Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior.

I think so, too.

--
Thorsten Wilms

On Wed, Jan 31, 2007 at 11:02:20AM -0800, Akkana Peck wrote:

Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time?

To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case).

That's pretty much all I use the delay for. Very, very occasionally I'll want to screenshot something that takes me a few seconds to set up, but mainly it's to take something on a different desktop. Generally these are large windows. I think that most of my screenshots are web pages, closely followed by bug reports (usually in Gaim). For both of these I much prefer not having the capturing window on the desktop, and with webpages I want as much of the app visible as possible. There is no room for both on my screen.

Hi,

On Wed, 2007-01-31 at 04:44 -0600, Clarence Risher wrote:

Perhaps there is no intentional support, but I guarantee you that gimp (as of 2.2, and i expect still in 2.3) takes screenshots of non-rectangular windows just fine. The result is a black rectangle containing the visible shape of the window.

See. I told you that shaped windows are in fact rectangular. All windows on the X window system are, by definition. The screenshot plug-in just takes a screenshot of that window and since it doesn't support asking it for the shape bitmap or the alpha channel, the result is rectangular and doesn't have any transparency.

Also, my silly xeyes idea brings up a point on the primary topic as well... I need a delay before selecting the xeyes window to get to the proper desktop, or bring it to the front, and a delay after selecting it because I dont want it to look crosseyed (for anyone who doesnt know, xeyes is two animated eyeballs that stare at the mouse cursor).

Your window system comes with a tool called xwd. If you are a fan of xeyes, you will also like xwd. It was written about around the same time.

Sven

Hi,

On Wed, 2007-01-31 at 11:02 -0800, Akkana Peck wrote:

In 'snap window' mode the shot shall be taken:

a) on the first mouse-down after the timer (can be zero) has expired; b) immediately, when a non-zero timer expires AND a mouse-button (left, right [pop-up menu], even middle?) is being held down.

That takes care of menus, but there transient effects which don't involve a mouse button down. For gimp, examples include the cursor outline of a brush, or the line you get pressing shift in a drawing tool.

You can take a screenshot of the brush outline and even the straight-line preview just fine with the screenshot plug-in from 2.3.x.

With the changes that I've done in SVN, you can screenshot pretty much everything. Sure, there will always be a few corner cases left unhandled. But these corner cases are just that, corner cases. As long as the user can somehow solve them, as long as the desired result can be obtained, perhaps with a little more effort, that should be fine.

Would still be nice if someone could find a way to ask X for the application window that a popup window belongs to. I haven't found a way to do that and the longer I stare at the XLib manuals, the more I start to believe that there is no clean way to do that.

Sven

Duh! caught out by this ML reply-to <> sender policy once more. Sorry.

------- Forwarded message ------- From: gg@catking.net
To: "Sven Neumann"
Cc:
Subject: Re: [Gimp-developer] Meaning of delay in screenshot plugin Date: Wed, 31 Jan 2007 10:51:12 +0100

On Wed, 31 Jan 2007 08:38:21 +0100, Sven Neumann wrote:

But I don't know all the other desktop environments out there and I expected that they more or less all have a reasonably well working way of taking screen-shots. After all this is where the functionality belongs.

Well there is no clear definition of the responsabilities of a desktop manager and different project chose different criteria. KDE tries to take over management of the whole system which I consider inappropriate but is very popular because it follows the windows thinking most people have been obliged to learn.

Other window managers, like fvwm, take a very minimalist approach that is close to a bare windows manager without any concept of desktop.

xfce4 aims for a balance somewhere in the middle, remaining light while providing basic desktop functions. I guess they think taking screen-shots is not part of desktop function and if you want that you'll install a tool like scrot or gimp.

I have even seen comments here suggesting this is a OS function. That only makes sense in the MS use of the term where the "operating system" can re-size images , zip them, open an Internet connection and send them to your grandma.

Clearly any correct use of the term has nothing to do with screen-shots, graphics or windows at all. It concerns making the hardware _operate_ .

There is a blurring of lines.

I don't see this as being out of place in a tool like gimp. It is after all a plugin , not part of the core. I don't think a desktop task-bar plugin is any more "right" than a image editor plugin. Why not both, I'll use the one that works best ;)

In any case, after a busy day on this topic yesterday, it seems like everyone is pulling in the same direction , attitudes are a lot more positive and it looks like the resulting plugin will be a lot more functional than any other screen capture tool I've seen. That's great news.

It raised my morale considerably to see a wide range of views, ideas and needs being distilled into an effective and flexible solution so quickly. This is OSS working the way it should work.

Good day to all.

gg

Sven wrote:

Would still be nice if someone could find a way to ask X for the application window that a popup window belongs to. I haven't found a way
to do that and the longer I stare at the XLib manuals, the more I start
to believe that there is no clean way to do that.

I got the feeeeling that ksnapshot manages to take a snapshot of the window + menu. There is where I got the idea. But reading the documentation again, they do not 100% promise this.

Can you recognise if a window is in fact a menu?

Can you keep track during the delay of every window that gets clicked in?

Then you have a chance of remembering the 'last real window' clicked in before the delay expired.

--ps

principal user interaction architect man + machine interface works

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

Akkana wrote:

I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users,

Not being an interaction architect, I'm still not understanding. How did you arrive at the 99% number?

I explained how I got to the 1%, the 99% are the rest of GIMP users. And 1% is already a very generous, on the safe side, estimate.

Do you really think you can round up ten thousand GIMP users who ever have to take a screenshot of a window with something pressed AND consider GIMP actually the right tool for this?

You'll struggle to find one thousand, exactly because most would not choose GIMP. But 1% is a convenient number and it drives the message home.

I simply want you to concentrate on 990000 GIMP users, who will never ever take a screenshot of a window with something pressed, with GIMP. Confront them with two delays, and you make them think what the difference is. You just stopped them working...

Now you take the same decision as I had to take.

[pre- vs. post- selection delay]

I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way.

To get the screenshot dialog out of the way, you mean?

No, to get GIMP out of the way. The 800 pound gorilla that eats a million pixels of screen real-estate for breakfast.

Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time?

To the list: does anyone here actually uses the delay for that purpose?
The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case).

In general the delay is 'time to get ready'. Get GIMP out of the way. This can be done in a multitude of ways, of which switching desktops is one.

I also wonder about discoverability: "Sometimes I have to click on the window after the delay, but sometimes I don't." Will people figure out that having a mouse button already pressed is what makes the difference?

I already asked for the improvement that we use two lines of text to explain what happens (depending on the snap option) during and after the delay.

Everything is cool with the interaction syntax, when the delay expires, the user says 'this one' by either clicking on it, or already holding it up by the ears.

And you know what? It feels really good that I have sped up your workflow, compared to 2.2, without making 990000 other users pay for that.

Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior.

Only if you have been taking many screenshots of stuff pressed in windows with GIMP for the last few years.

Putting the two delays in the UI on the same level is a big mistake, actually. Makes one even more think "what is this selection..?" The 2.2 dialog did that better.

--ps

principal user interaction architect man + machine interface works

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

This discussion goes on too long and distracts too much. I am one who would prefer the plugin to work differently, but it is clear that no solution will be good for everybody, and the approach Sven has taken is certainly reasonable.

It would also be reasonable, I think, to separately distribute a "fancy-screenshot" version, perhaps via the registry, that would allow more options for handling the delay.

Best wishes,

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

peter sikking writes:

I got the feeeeling that ksnapshot manages to take a snapshot of the window + menu. There is where I got the idea. But reading the documentation again, they do not 100% promise this.

I should have tried ksnapshot before! It does get the menus -- even on Edgy where GIMP's snapsnot just gets garbage. If you have the mouse over only a menu, ksnapshot will even give you just the menu without the window containing it.

ksnapshot solves the delay problem in a nice clean way: they have only one (pre-selection) delay, but their window selection is "Window under cursor" -- you don't need to click to select the window. That solves everything without requiring two delays. It's a nice solution!

(Now off to poke around X and think about Sven's fabulous super- layered-screenshot idea.)

Hi,

On Thu, 2007-02-01 at 10:37 -0800, Akkana Peck wrote:

If you have the mouse over only a menu, ksnapshot will even give you just the menu without the window containing it.

ksnapshot solves the delay problem in a nice clean way: they have only one (pre-selection) delay, but their window selection is "Window under cursor" -- you don't need to click to select the window. That solves everything without requiring two delays.

This is exactly how the GIMP screenshot plug-in in SVN behaves.

Sven

On Tue, 2007-01-30 at 12:36 -0800, Akkana Peck wrote:

For what it's worth, every time I see the question "How do I make a screenshot?" posed on a beginner/intermediate Linux list, the answer always ends up being GIMP. It's still the best method that's not dependent on users running specific versions of specific desktops.

Personally I'd rather have the screenshooter be a separate application. There is a good number of efficient workflows using existing tools (`sleep 5 && import (-window root) ~/Desktop/foo.png` [1], `gnome-panel-screenshot --delay 5 (--window)` , ksnaphot (don't know my way around that one)).

I consider the GIMP's screenshooter served its historical purpose, but isn't as needed even though some of us have grown familiar with it. You have to look at it pragmatically. Too few resources, lots of more important code to maintain.

cheers

[1] http://www.graphicsmagick.org/www/import.html [2] http://en.wikipedia.org/wiki/KSnapshot

On 2/5/07, Jakub Steiner wrote:

Personally I'd rather have the screenshooter be a separate application. There is a good number of efficient workflows using existing tools (`sleep 5 && import (-window root) ~/Desktop/foo.png` [1], `gnome-panel-screenshot --delay 5 (--window)` , ksnaphot (don't know my way around that one)).

Shouldnt a (possibly slightly less) simple one-liner be possible piping script-fu to gimp to call the screenshot plugin's APId function(s)? IMHO, we need to keep in mind that things accessible on the interface dont neccessarily define the capabilities of the back end.