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 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
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] changes in script-fu in 2.3.14
Date: Tue, 30 Jan 2007 17:24:59 +0200 From: Alexander Rabtchevich <[EMAIL PROTECTED]> Raphaël, this IS exactly my point! Why should the global variables be prohibited if there is no difference in memory consumption with local ones, only additional efforts to a programmer to track all parenthesis. The common namespace is the other problem - it is due the luck of interpreter usage or implementation, not the language itself. > Also, does it make sense to worry about leaving a variable and > its context in memory for a little while when this variable only > takes a few bytes and the data that you are manipulating is > several orders of magnitude larger? Keeping an integer and its > context on the stack means almost nothing in comparison with the > megabytes of image data that the script is processing. Raphael is quite correct. Global variables are serious bad juju in this situation. The basic problem here is that script-fu runs all scripts in the same environment. It isn't invoked separately for each plugin. This means that any plugin that uses a global variable without setting it first (basically, an unitialized variable) is at the mercy of any other plugin that may have set that variable. That means that if the programmer isn't careful the results obtained will depend upon what happened to be run previously -- in other words, plugins may give different results depending upon what happened before. If you're going to initialize all global variables each time you run a script (which is the only safe thing to do, for the above reason), you might as well just not use them, since they're effectively going to be local, anyway. The first time you have to track down a bug caused by cross-script global variable pollution will cost you more time than *all* of the time you spend tracking parentheses on every script you write in your lifetime, practically guaranteed. I remember one bug that took me something like 12 hours to find, in 6.001 (the intro programming class at MIT -- taught in Scheme, at least when I was there). It was due to a variable in the project code that was named "exp" that I was somehow picking up (I've long since forgoten the details -- I fired off an angry and frustrated email to Sussman and Abelson, and received a prompt apology). A few of those will change one's outlook in a hurry. I won't go so far as to say that global variables should *never* be used -- just like all good rules, there are exceptions. A shared environment that's running many programs without any namespace separation is one place where there really should *never* be global variables that the individual programs can use read/write (as opposed to global read-only variables exported by the environment, which are safe). Statically scoped variables would be safe enough; I don't recall that Scheme supports them (as I recall, everything in Scheme is supposed to be lexically scoped). -- 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 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
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
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 <[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 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
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
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 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
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] changes in script-fu in 2.3.14
Sven Neumann writes: > On Tue, 2007-01-30 at 08:22 +0100, Sven Neumann wrote: > > > I don't think that the NEWS file is the right place for this. Someone > > should set up a detailed description of the changes with instructions on > > how to fix scripts that stop working after the update. We should then > > refer to this document from the 2.3 release notes (and of course also > > from the 2.4 release notes when they are written). > > Any volunteer for this? Doesn't that require someone with a good knowledge of what all the changes are? If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that. -- ...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
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
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
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, 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
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
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
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!) -- ...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 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] changes in script-fu in 2.3.14
Hi, On Tue, 2007-01-30 at 08:22 +0100, Sven Neumann wrote: > I don't think that the NEWS file is the right place for this. Someone > should set up a detailed description of the changes with instructions on > how to fix scripts that stop working after the update. We should then > refer to this document from the 2.3 release notes (and of course also > from the 2.4 release notes when they are written). Any volunteer 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
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 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
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] changes in script-fu in 2.3.14
Alexander Rabtchevich ([EMAIL PROTECTED]) wrote: > Raphaël, this IS exactly my point! Why should the global variables be > prohibited if there is no difference in memory consumption with local > ones, only additional efforts to a programmer to track all parenthesis. Because global variables are not allowed in scheme and global variables are bad programming practice anyway (in basically all programming languages). And misuse can do great harm - we've seen that. 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] changes in script-fu in 2.3.14
Raphaël, this IS exactly my point! Why should the global variables be prohibited if there is no difference in memory consumption with local ones, only additional efforts to a programmer to track all parenthesis. The common namespace is the other problem - it is due the luck of interpreter usage or implementation, not the language itself. > > Also, does it make sense to worry about leaving a variable and its context > in memory for a little while when this variable only takes a few bytes and > the data that you are manipulating is several orders of magnitude larger? > Keeping an integer and its context on the stack means almost nothing in > comparison with the megabytes of image data that the script is processing. > > -Raphaël > ___ -- 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] changes in script-fu in 2.3.14
On Tue, 30 Jan 2007 16:06:00 +0200, Alexander Rabtchevich <[EMAIL PROTECTED]> wrote: > Some more thoughts on local variables in scheme from a newbie POV. > > Due to a parenthesis syntaxes of variable declaration area, if variable > x is declared before variable y and y is declared before x is dropped, x > remains active at least until y is dropped. [...] So what? Keep in mind that premature optimization is the worst ennemy of the developer. Script-Fu was never designed to be especially efficient: it was designed to get the job done with a minimum amount of developer effort. Also, does it make sense to worry about leaving a variable and its context in memory for a little while when this variable only takes a few bytes and the data that you are manipulating is several orders of magnitude larger? Keeping an integer and its context on the stack means almost nothing in comparison with the megabytes of image data that the script is processing. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
Some more thoughts on local variables in scheme from a newbie POV. Due to a parenthesis syntaxes of variable declaration area, if variable x is declared before variable y and y is declared before x is dropped, x remains active at least until y is dropped. (let (x 1) ... (let (y 2) ;x is used here ... ;noway to drop x here ) ;let (y ) ;(let (x So there is no much benefit from such a manner of local variable definition in sense of memory consumption. -- 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
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
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
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, 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 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
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
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] changes in script-fu in 2.3.14
On Tue, 30 Jan 2007 08:24:40 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > On Tue, 2007-01-30 at 09:11 +0200, Alexander Rabtchevich wrote: > > But the inability to use global > > variables along with scheme syntaxes leads to a good deal of parentheses > > which could be a problem to a programmer. > > I don't see how this introduces the need for more parentheses. Just to prove that point, a couple of weeks ago I fixed a bug in a script that looked like this: (define (some-function ...) (begin (set! undeclared-var some-value) (... more code ...) )) Fixing this problem was easy and made the code shorter: (define (some-function ...) (let ((declared-var some-value)) (... more code ...) )) -Raphaël ___ 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
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
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] combine crop with scaling
Hi, On Tue, 2007-01-30 at 10:22 +0200, Alexander Rabtchevich wrote: > Current crop implementation (2.3.14) is very nice though it lacks a > listbox with user-defined ratios. I really love it. The 2.3.14 has > introduced a little inconvenience from my POV: the corner rectangles are > too much bright. They interfere with an attempt to value the composition > while framing. Could they become less in size and dimmer? Could the > saturation of the frame itself become dimmer or be changed by user? The > idea of colour inversion (or difference) is wonderful itself. Please read the spec that Peter sent to the list. It clearly explains why the corner frames are so important. We would like them to be alpha-transparent overlays but that's not possible with the current display drawing code. After a lot of experiments we settled for what we have now. I don't think we are going to change that. When 2.4 is out I would like to port the display to using Cairo and that should allow us to change all this to the better. Until then, please try to understand that we need to concentrate on the important bits now. > There are several requests on Russian Gimp list to combine cropping and > scaling. I'd ask it too. The new rectangle tools are far from being finished. The original authors have stopped working on them and it seems that no one is willing to fix the remaining issues (and there are quite a few of them). So please, by all means, don't bring up new features now. Currently it seems rather unlikely that we will ever get 2.4 out with the planned feature set. 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] changes in script-fu in 2.3.14
Hi, On Tue, 2007-01-30 at 09:55 +0200, Alexander Rabtchevich wrote: > So if the scripts were loaded dynamically on demand: If I understood Kevin correctly the long-term goal for Tiny-Fu is to start the interpreter on demand for each script that is executed. So at some point scripts will behave more like plug-ins. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] combine crop with scaling
Current crop implementation (2.3.14) is very nice though it lacks a listbox with user-defined ratios. I really love it. The 2.3.14 has introduced a little inconvenience from my POV: the corner rectangles are too much bright. They interfere with an attempt to value the composition while framing. Could they become less in size and dimmer? Could the saturation of the frame itself become dimmer or be changed by user? The idea of colour inversion (or difference) is wonderful itself. There are several requests on Russian Gimp list to combine cropping and scaling. I'd ask it too. My typical workflow always contains these operations one after another if fixed ratio is used. I crop the image with fixed ratio, defined by desired picture size, say 1795x1205. The aim is to obtain a final picture of 1795x1205 pixels. So the second operation is to scale the result of the crop to 1795x1205. If a crop tool contained a checkbox: scale to the fixed ratio pixels, one wouldn't have to: select scaling from the menu, type one of the sizes and click scale. -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
