Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 -- Jakub Steiner [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 2/5/07, Jakub Steiner [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 99 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 99 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
peter sikking writes: I got the fling 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.) -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/31/07, Sven Neumann [EMAIL PROTECTED] 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). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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. -- Alex Pounds (Creature) .~. http://www.alexpounds.com/ /V\http://www.ethicsgirls.com/ // \\ Variables won't; Constants aren't /( )\ ^`~'^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 31 Jan 2007 08:38:21 +0100 On Tue, 2007-01-30 at 22:03 +0100, [EMAIL PROTECTED] 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. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, Sven Neumann [EMAIL PROTECTED] 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) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Hi, On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote: On 1/30/07, Sven Neumann [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, Sven Neumann [EMAIL PROTECTED] wrote: On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote: On 1/30/07, Sven Neumann [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Clarence, would it be better to be not so aggressive? ;) -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Sven Neumann ([EMAIL PROTECTED]) 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 -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
From: Sven Neumann [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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? -- Jernej Simončič http://deepthought.ena.si/ The solution to a problem changes the problem. -- Peer's Law ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On Tue, Jan 30, 2007 at 01:10:56PM +0100, [EMAIL PROTECTED] 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. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, Marco Ciampa [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 01:10:56PM +0100, [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Date: Tue, 30 Jan 2007 15:13:45 +0300 From: Alexandre Prokoudine [EMAIL PROTECTED] 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. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Hi, On Tue, 2007-01-30 at 13:10 +0100, [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On Tue, 30 Jan 2007 20:04:31 +0100, Akkana Peck [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, peter sikking [EMAIL PROTECTED] 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) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 (Creature) .~. http://www.alexpounds.com/ /V\http://www.ethicsgirls.com/ // \\ Variables won't; Constants aren't /( )\ ^`~'^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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/ 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. PS. I know nothing about gtk, so the patch may be not very beautiful, but it works nicely. PS2. I really like the new interface of the screenshot plugin. In contrast, the old seems just ugly :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 Pout of a image in GIMP, or two added rectangles (window + Pmenu 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 [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, peter sikking [EMAIL PROTECTED] wrote: Clarence Risher wrote: On 1/30/07, peter sikking [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On Tue, 30 Jan 2007 20:22:11 +0100, Sven Neumann [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Hi, On Tue, 2007-01-30 at 22:03 +0100, [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
