Re: Meaning of delay in screenshot plugin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux