Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

[Sven Neumann]

Hi,

On Thu, 2007-03-22 at 06:02 +0200, Shlomi Fish wrote:

> Well, I don't believe spending 10 minutes writing an email is a waste. I 
> spend 
> more time on most serious emails. When I write emails I invest a lot of 
> conscious effort writing them.

Does this mean that you are volunteering to handle the 5 to 10 bug
reports that are coming in daily, as well as all the "stupid" questions
on gimp-user and gimp-developer? If each of them takes you ten minutes
to deal with, you aren't going to have time for anything else in your
life.

It is IMO very important that each bug report is handled quickly and
that all questions are answered. I can spend about half an hour per day
on this. That is not an excuse for being rude, I am only pointing out
that you are asking for too much. We should definitely improve our tone
and it will probably help to spend a few extra seconds per request. But
if ten minutes is the required amount of time that needs to be spent on
a bug report or for answering an email, then I am out.

Even reading your mails takes way too much of my time. I definitely
prefer a short text that comes to the point quickly. And you should
reconsider your use of footnotes in emails. No, it doesn't improve the
reading experience as it forces me to scroll up and down.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] A request for your input.

[lmth]

Hello

My name is Lara Thynne and I am a PhD candidate at Deakin University
Australia.  I am currently researching the boundary between work and
leisure activities directly related to the open source community and
open source program development.

As part of this I am running a survey at the following address.

https://dcarf.deakin.edu.au/surveys/oss/

The survey is completely confidential and looks at your views and
motivations to use Open Source software and to participate in the
community.

It will only take a five to ten minutes to complete and your contact
details will not be recorded. You can withdraw your participation at
any stage.

I sincerely apologize for the spammish nature of this e-mail - I
don't mean to abuse this list.  I am trying to collect responses
from as many open source developers and users as possible and a
mailing list like can be the only way to reach many developers.

Thanks again

Lara

P.S The program that I am using is open source, of course
(www.phpsurveyor.org)!




___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

[Shlomi Fish]

On Wednesday 21 March 2007, Simon Budig wrote:
> Shlomi Fish ([EMAIL PROTECTED]) wrote:
> > On Tuesday 20 March 2007, Simon Budig wrote:
> > > Shlomi Fish ([EMAIL PROTECTED]) wrote:
> > > > It took me 10 minutes to write.
> > >
> > > Oh wow. Is it just me or is this really a *lot* of time? Personally I'd
> > > consider answering 6 "lazy questions" per hour a waste of time.
> >
> > Well, a few notes:
> >
> > 1. I didn't measure how much time it took me exactly. It was probably
> > less than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.
>
> Ok, granted. I was just surprised that you'd seem to take this as
> something not noteworthy.
>

Well, I don't believe spending 10 minutes writing an email is a waste. I spend 
more time on most serious emails. When I write emails I invest a lot of 
conscious effort writing them. Most of the time I read the email to which I 
respond to the end before hitting the reply button. And most of my important 
emails are properly-cased, and with as few 
spelling/grammatical/syntactical/etc. problems as I possibly can, with me 
even trying to use the best possible phrasing. All of which subject to the 
fact that English is my second language, and that I have audible perception, 
which makes several ("It sounded so much better in my head" or mispelling 
words, especially of similar sounds) more often than people with visible 
perception.

I enjoy writing emails? Would I prefer to write code? Probably. However, even 
code is not the most productive thing. To paraphrase on what an article I 
read said the most productive thing a businessman makes are crucial decisions 
which radically change the way your business operates. The analogy to the 
FOSS world is that people who only write code (even exceptionally good code 
and a lot of it) are not as productive as people who define a better strategy 
for their code and projects. If I have speactacular code which is available 
only from some directory on an obscure FTP server, it would not be as ideal 
as me deciding to have a decent homepage for it with a download link and an 
archive containing the version number in the filename, etc. Most people take 
it for granted, but I've seen many exceptions to even this rule.

Now take it further. Deciding to write a FAQ was a critical decision. Now 
writing it would be the easy and relatively brainless part.

> > 2. I had to find a URL which more experienced developers would know by
> > heart.
>
> That is a misconception. I personally do know exactly one URL of the
> website by heart: "http://www.gimp.org/";, ok, two:
> "http://www.gimp.org/tutorials/";. Everything else is opening it
> in the browser and search for the appropriate link (which in this case
> is prominently in the menu structure). I do believe that this is the
> same for all developers not actively working with the site itself.
>

OK, my bad.

> > 3. 10 minutes is much less time consuming that writing a bug-fix or an
> > enhancement patch for the GIMP or for any other program. If it takes me
> > 10 minutes to answer someone in a polite, friendly and encouraging way
> > and he or she later become an active developer, then I may have "wasted"
> > 10 minutes, but subsequently got hours and days of voluntary development
> > in return.
> >
> > Which alternative is better? You decide.
>
> Well, if it were fun to answer these kind of obvious questions that two
> minutes researching on the gimp homepage would have solved then you'd
> have a real point. It is not fun though. To the contrary.
>
> And frankly, we put a lot of effort into the source package to make it
> as easy to compile as possible. I firmly believe that the quality of
> GIMPs code is a lot better than that of a lot of other free software
> projects, mostly because especially Mitch and Sven have very strict
> guidelines for patches.
>
> Then somebody comes and asks if Gimp is written in C/C++? I mean, come
> on. That is like asking "I want to become a computer scientist. How does
> a computer work?". It is just a painful question.
>

I know it's a stupid question, but believe it many people come to the Technion 
CS/EE/Math/Industry&Management/etc. departments without any seriuos 
programming knowledge. I once helped two people - a guy and a pretty girl - 
who never operated a spreadsheet - not even Excel, which is what we had on 
the Windows network.[1] And they were EE students in their 4th semester with 
decent or better grades. And some of them actually become decent or even very 
decent programmers or engineers. And the vast majority of them get infested 
with a lot of nearly useless knowledge, part of which as far as many EE 
graduates are concerned is understanding how every level of a computer works 
down to the semi-conductors.[2]

Where was I? Yes, I know it was a stupid question. But it does not 
specifically say so on the site very well. Do we have a technologies we use 
page and/or Lines of codes counts page on the site? I don't think we do. We 

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla

[William Skaggs]

What fun!

Curiosity piqued, I tried to do some quasi-controlled analysis, using
the following method.  For various values of "foo", I did a Google
search for "foo developers rude" and then for "foo developers
friendly", and computed the ratio of the number of hits, yielding the
RQ or "rudeness quotient" for foo.

Here are the RQ's for a few foo's:


baseline (foo = ""): 0.064

SOFTWARE:

gimp: 0.314
photoshop:0.411
gnome:0.199
linux:0.044
linux kernel: 0.212
kde:  0.160
inkscape: 0.006
krita:0.021
blender   0.181

ORGANIZATIONS:

fsf:  0.392
microsoft:0.067
adobe:0.313
oracle:   0.206
ibm:  0.274

COUNTRIES:

american: 0.045
german:   0.243
canadian: 0.009
french:   0.116
indian:   0.114
finnish:  0.340
norwegian:0.394

QUALITIES:

hacker:   0.571
brilliant:0.791
elite:0.769
incompetent:  0.344
stupid:   0.819

So it seems that the least rude are Inkscape developers and Canadians.
The rudest are the "stupid" developers, followed closely by the
"brilliant" ones.

  -- 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] Rudeness on gimp devel and bugzilla

[Sven Neumann]

Hi,

I don't think that comparing projects will give us a lot insight. It
seems pretty clear to me that the main problem in GIMP development is
our long development cycle. This makes users believe that the project
would be stagnant and it takes a lot of fun out of the development. If
someone contributes a new feature it takes years before it reaches our
user base. And we are also going through long periods where we are more
or less feature frozen. That keeps us from accepting contributions such
as for example the Deskew plug-in which has been announced here
recently.

On the other hand we have very high quality standards and that is also
acknowledged. If we release something as stable, than it is really quite
stable and polished. Bug reports are handled very fast, serious problems
are usually fixed in at most a few days.

It remains to be seen if we can acomplish shorter development cycles and
still provide high quality software with a backward compatible API.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

[Shlomi Fish]

Hi Simon!

Let me just say that I found your response (and your response to my other 
email) well-thought and constructive, and generally agreeable. However, now I 
have some higher priorities (not GIMP related unfortunately) so I will 
reply[1] to this email later when I have some spare cycles.

But thanks for a great response.

Regards,

Shlomi Fish

[1] "Will reply" is subject to the Rule of Open-Source Programming[2] No. 11, 
which says that when a developer says he will work on something, then he or 
she means "maybe".

[2] - http://www.shlomifish.org/humour/fortunes/osp_rules - and yes, most of 
them are my own invention. Read at your own risk and take with a grain of 
salt.

On Wednesday 21 March 2007, Simon Budig wrote:
> Shlomi Fish ([EMAIL PROTECTED]) wrote:
> > On Tuesday 20 March 2007, Simon Budig wrote:
> > > Shlomi Fish ([EMAIL PROTECTED]) wrote:
> > > > It took me 10 minutes to write.
> > >
> > > Oh wow. Is it just me or is this really a *lot* of time? Personally I'd
> > > consider answering 6 "lazy questions" per hour a waste of time.
> >
> > Well, a few notes:
> >
> > 1. I didn't measure how much time it took me exactly. It was probably
> > less than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.
>
> Ok, granted. I was just surprised that you'd seem to take this as
> something not noteworthy.
>
> > 2. I had to find a URL which more experienced developers would know by
> > heart.
>
> That is a misconception. I personally do know exactly one URL of the
> website by heart: "http://www.gimp.org/";, ok, two:
> "http://www.gimp.org/tutorials/";. Everything else is opening it
> in the browser and search for the appropriate link (which in this case
> is prominently in the menu structure). I do believe that this is the
> same for all developers not actively working with the site itself.

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] despeckle plugin

[Luis A. Florit]

Pals,

The Despeckle plugin shipped with GIMP 2.3.15 has a strange
behavior: it shifts the image 1 pixel to the right, and one down,
at least in some channles. Compare with the plungin in gimp 2.2.
Probably you already observed this.

Thanks,

Luis.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla

[Raphaël Quinet]

On Wed, 21 Mar 2007 10:41:48 -0700, Manish Singh <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 21, 2007 at 08:00:42AM +0100, Martin Nordholts wrote:
> > Though, Inkscape I think seems to have succeeded better than both GIMP
> > and Krita (attatching new and prettier script version)
> 
> Yeah, but not by much. The point being, pretty much all free software
> projects could use more contributors, and I don't think perceived
> rudeness is the primary cause of this. The Linux kernel folks are far
> ruder than anything that's happened on this list, but the number of
> contributors is in the thousands.

We seem to have a rather bad reputation, though.  Try the following
totally unscientific exercise: associate the terms "gimp developers" or
"gimp contributors" or "gimp hackers" or "gimp admins" (including the
quotes) with words such as rude, arrogant, unfriendly, assholes and so
on.  Then count the number of pages that are found for each of these
combinations using your favorite web or newsgroup search engine.

Continue this exercise by taking a random sample of these hits, checking
how many of them actually accuse the developers of being rude versus how
many are just accidental associations due to the fact that these terms
appear on the same page but in different contexts.  And adjust the total
number of hits according to the proportion found in the random sample
(the other option is to perform an exhaustive review of all hits - good
luck with that).

Now that you have these unscientific numbers for GIMP, repeat the
exercise for "Linux developers", "kernel developers", "GNOME developers",
"Inkscape developers", and so on with Krita, KDE, Mozilla, OpenOffice...
Of course these numbers have to be weighted according to the total number
of hits without the derogative terms (e.g. "gimp developers" without
"rude", etc.)

I did not waste too much time on this pointless exercise, but it looks
like GIMP does have a bad reputation, as it comes first or second in the
associations with "rude", "arrogant", "unfriendly", etc.  The Linux
kernel guys are a bit more rude and the GNOME developers are more arrogant
(but not so rude nor unfriendly).  But overall, GIMP scores rather high.
It will probably take a long time to change that perception...

Note that I do not intend to continue this discussion nor to perform this
silly exercise in depth.  We have already discussed this long enough and I
hope that we will all be a bit more careful when replying to questions or
bug reports.  For Bugzilla, I think that the general guideline would be to
always thank the reporte, even if the bug report is not so good.

-Raphaël
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla

[Manish Singh]

On Wed, Mar 21, 2007 at 08:00:42AM +0100, Martin Nordholts wrote:
> Though, Inkscape I think seems to have succeeded better than both GIMP
> and Krita (attatching new and prettier script version)

Yeah, but not by much. The point being, pretty much all free software
projects could use more contributors, and I don't think perceived
rudeness is the primary cause of this. The Linux kernel folks are far
ruder than anything that's happened on this list, but the number of
contributors is in the thousands.

-Yosh
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier

[peter sikking]

Sven wrote:

>> I am not sure if Sven wants another feature request in bugzilla.
>> If so I will write it.
> Yes sure. We have discussed the feature here and now we should make a
> useful bug report from it. That will help to remember the outcome  
> of the
> discussion and it might attract a developer who wants to work on this
> feature. I am not at all opposed to bug reports.

just checking, because of:

> I just doubt that it makes much
> sense to keep adding enhancement requests without discussing them
> beforehand. We currently have about 600 open bug reports, most of them
> enhancement requests.

then saul wrote:

>> I would spec some things different than saul shows us here:
>> enlarged area much closer to the smaller mouse area;
>> semitransparent frame to make the tool less obstructive;
>> real tool display in the enlarged area.
>
> Indeed, the "handle" of the loupe tool in my simulation is much longer
> than it should be (and the frame should have been translucent). I did
> not realize this until after I had generated the file (a process which
> took my puny 'puter quite a while to accomplish).

my thanks for you and the 'puter, again.

> Firstly, there is an effective "warping" of the pointer when the tool
> is invoked whereby the focal point is relocated and the user must find
> it. While such warping is discouraged by GNOME Human Interface
> Guidelines (HIG), in this case it is probably acceptable (and one
> could argue that the focal point is actually the small view port and
> is not warped).

the last point is exactly how it works (also for humans) and means
no HIG felonies.

> Nonetheless, this behavior can be disorienting. It
> should be noted that the overly-long "handle" shown in the simulation
> exaggerates the severity of this problem.

the point of my 'must be close, but out of the way' guiding principle.

> More important is the general nature of the "tracking" of the
> different elements of the loupe in response to mouse movement and the
> dichotomous nature of the user's focus (i.e., whether his attention is
> on the view's port or the zoomed port).

that is at the user's discretion.

> I would assume (and this is not shown in the simulation) that when the
> loupe is invoked, the resolution of the mouse movement switches to
> that of the zoomed view.

excellent point. since the point of the loupe is working precise,
the mouse must move at the speed of the zoomed view.

> The change in orientation of the loupe when it
> approaches the window's limits results in rather serious
> disjointedness between mouse movement and the zoomed port (though the
> view's port would continue its original behavior). Perhaps a better
> solution than that shown in the simulation is available.

your solution really got me thinking. there are multiple other
alternatives. at the end it is about having the most stable,
predictable loupe placement, and technical feasibility.

> The zoomed image in the larger port would move in the opposite
> direction of the mouse movement in order to track the image properly.

well, if you want to see the spec of dust to the top-left of your
current view better, you move the mouse top-left, and you see the
spec of dust centred. sounds good to me...

> While there are certainly similar loupe "gadgets" present in a few
> other programs, the only ones I have encountered are more interested
> in _viewing_ things at a microscopic scale and not actually _working_
> at that level. I am suspicious that the more intense focus of the user
> entailed will exascerbate the disparities in the screen response to
> mouse movements.

we really will have to work hard to make this reach the transformative
potential it has. Working with it is the highest goal.

 --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] Rudeness on gimp devel and bugzilla - was:?Re: Tools

[Simon Budig]

Shlomi Fish ([EMAIL PROTECTED]) wrote:
> Actually I also think it was too rude. Let's analyze it:
[...]
> 1. You didn't say "hi".

Oh, come on. A lot of the mails on mailinglists don't include a greeting
if quoting something. I've never perceived that as *rude*.

> 2. You phrased it as a question that implied the original poster should have 
> thought abuot it himself, instead of giving an answer.

Oh, come on again. It is not unusual to formulate a suggestion in terms
of a question. To pose this as rude is IMHO blown way out of proportion.

I really don't get why this discussion sparked from this specific mail.
Please also keep in mind that most of us are *not* native speakers and
discussing stuff in this linguistic nuances is probably a wasted effort.

[...]
> However, I believe Alpár's and Joao commentary was induced by the general 
> trend of treating people on this list (and potential future contributors) 
> rudely or impatiently. I've noticed this general trend here too after someone 
> made me more aware of it.

Funny, my impression is, that it got better in the last few months.

> I believe the GIMP could have been much better off today, if it weren't for 
> all the antagonism that the developers' have created. I mean, sure after 
> Spencer Kimball and Peter Mattis left the project and most of the other 
> original developers left to work on GNOME, very few developers were left. But 
> since then the community of FOSS developers grew by leaps and bounds, and 
> there shouldn't have been any problem finding much more potential developers 
> than we have today. There are plenty of fish in the sea.

I am concerned that this might not be exactly true. I don't have
specific numbers, but my impression is, that it is way harder to sort
the wheat from the chaff nowadays. In the beginning of the GIMP the
people who a) found the GIMP, b) bothered to subscribe to the
mailinglist, c) expressed interest in contributing generally already
were enthusiasts about free software. They used stuff like e.g.
slackware to convince their boxes to boot into linux. They were editing
textfiles to get an internet connection. They had a thorough
understanding of their system. This is no longer the case today. I mean,
I am teaching stuff at the CS department of our universities and there
really are students here who never did any programming and/or are
annoyed if they have to. I mean, WTF?

Granted, the pool became bigger, but the amount of fish in it did not
increase in the same proportion. And there are a lot more projects
fishing around in there.

I am not sure if this is a fair description, I probably sound a little
bit like a grumpy old man. Not sure what to do about this though...  :)

> Let's look at Inkscape for a counter example. They have been around
> for a much shorter time than the GIMP, but have made remarkable
> progress, because the atomosphere they have is much better. If they
> could do it, why can't we? Only because we reject potential
> developers.

I believe that "reject" is the wrong word here, because it implies that
we'd do this on purpose which is in general not true. We do have a habit
of expecting a lot from patches (look at the number of iterations some
patches go in bugzilla) but in general I believe that even the original
patch author will agree that the result is way better than what was
originally submitted. We also have the habit of expecting more than
half-baked ideas when someone comes up with an idea and sometimes ideas
are probed a lot before a developer admits that it might be a good idea.

I guess that these intentions do not always make it through to the
person presenting the idea and they take it as a hostile attitude of the
gimp developers (sometimes even "threatening" us with switching to other
applications). This is the area where we probably can improve things
a lot by being more careful with the language. However, the probing in
itself is necessary and important for the quality of the Gimp.

[and regarding inkscape - I like the project a lot and I don't mean them
any harm, but they lost me as a contributor even before I tried to
communicate with them - 430 source files in a single directory is a good
way to do this, hopefully they will improve there.]

About your suggestions:
> 1. Create a page with some FAQs and canned responses in both HTML and plain 
> text formats. I volunteer to prepare and maintain this page. I also get sick 
> of reading more "You should change the name of the GIMP, it is an insult in 
> English", "When is CMYK/16-bit/whatever support coming?", etc. questions, but 
> I believe we can at least answer them politely.

Please add "I will switch to [whatever]" to that list...

> 2. Have a system of self-moderation. Let the messages of developers with a 
> tendency to be rude and untactful pass through a small forward 
> of "friendliness experts" for approval and correction. IF the experts are 
> unhappy, they'll tell the senders to edit them and re-send them.
> 
>

Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier

[Mark Lowry]

I think that the user should be able to select between
a 1:1 mouse resolution scale and one that matches the
scaling of the loupe's zoom.  This would be good to
offer at least on any test version that is developed,
until enough user feedback is obtained to eliminate
one of the options.


--- [EMAIL PROTECTED] wrote:

> I would assume (and this is not shown in the
> simulation) that when the  
> loupe is invoked, the resolution of the mouse
> movement switches to  
> that of the zoomed view. This assumption may be
> faulty but it would  
> seem that if you are zoomed in at 10X and the mouse
> inputs are not  
> scaled appropriately then you will experience
> difficulty with  
> positioning of the tool within single-pixel
> precision (in the zoomed  
> port). If sub-pixel mouse resolution is high enough
> than the loupe  
> could track the mouse 1:1 and the image in the
> zoomed port could track  
> it at 10X the speed (or whatever the zoom factor is
> set at) -- I don't  
> believe this to be the case.
> 
> The simulation shows a 4X zoomed version of the
> image in the larger  
> port. Based on the preceding assumption, the
> movement of the loupe  
> itself would become 1/4th the movement of the mouse
> pointer when the  
> loupe is not invoked. The change in orientation of
> the loupe when it  
> approaches the window's limits results in rather
> serious  
> disjointedness between mouse movement and the zoomed
> port (though the  
> view's port would continue its original behavior).
> Perhaps a better  
> solution than that shown in the simulation is
> available.
> 
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
>
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
> 



 

Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier

[saulgoode]

WARNING TO DIALUP USERS! The GIF file linked to in this post weighs in  
at 2.2Mb.

Quoting peter sikking <[EMAIL PROTECTED]>:

> "saul" on the irc made this film (thanks):
>
> 
>
> I could imagine here some dust spotting going on, on a
> macroscopic scale the photog decides what really needs to be
> spotted, pops up the loupe and makes a precise change.
>
> I would spec some things different than saul shows us here:
> enlarged area much closer to the smaller mouse area;
> semitransparent frame to make the tool less obstructive;
> real tool display in the enlarged area.

Indeed, the "handle" of the loupe tool in my simulation is much longer  
than it should be (and the frame should have been translucent). I did  
not realize this until after I had generated the file (a process which  
took my puny 'puter quite a while to accomplish). The "red dot" which  
I employed in the zoomed porthole of the loupe would be replaced by a  
cursor/outline representing the active tool (but my main concern was  
with the relative motions of the different elements).

Personally, I am not that enthusiastic about the proposed loupe  
gadget's interface and consider a "dockable tracking view" to offer a  
better solution. It is not a firm aversion to the loupe but more just  
reservations about the "comfort" of its use. I would not discourage  
anyone from actually producing a test implementation.

Firstly, there is an effective "warping" of the pointer when the tool  
is invoked whereby the focal point is relocated and the user must find  
it. While such warping is discouraged by GNOME Human Interface  
Guidelines (HIG), in this case it is probably acceptable (and one  
could argue that the focal point is actually the small view port and  
is not warped). Nonetheless, this behavior can be disorienting. It  
should be noted that the overly-long "handle" shown in the simulation  
exaggerates the severity of this problem.

More important is the general nature of the "tracking" of the  
different elements of the loupe in response to mouse movement and the  
dichotomous nature of the user's focus (i.e., whether his attention is  
on the view's port or the zoomed port).

I would assume (and this is not shown in the simulation) that when the  
loupe is invoked, the resolution of the mouse movement switches to  
that of the zoomed view. This assumption may be faulty but it would  
seem that if you are zoomed in at 10X and the mouse inputs are not  
scaled appropriately then you will experience difficulty with  
positioning of the tool within single-pixel precision (in the zoomed  
port). If sub-pixel mouse resolution is high enough than the loupe  
could track the mouse 1:1 and the image in the zoomed port could track  
it at 10X the speed (or whatever the zoom factor is set at) -- I don't  
believe this to be the case.

The simulation shows a 4X zoomed version of the image in the larger  
port. Based on the preceding assumption, the movement of the loupe  
itself would become 1/4th the movement of the mouse pointer when the  
loupe is not invoked. The change in orientation of the loupe when it  
approaches the window's limits results in rather serious  
disjointedness between mouse movement and the zoomed port (though the  
view's port would continue its original behavior). Perhaps a better  
solution than that shown in the simulation is available.

The zoomed image in the larger port would move in the opposite  
direction of the mouse movement in order to track the image properly.  
Within the large port, this behavior of mouse movement not resulting  
in movement of the pointer, but in the scrolling of the image behind  
it is somewhat non-standard (excepting for traditional cases where a  
pointer butts up against a window border, resulting in scrolling of a  
view window).

While there are certainly similar loupe "gadgets" present in a few  
other programs, the only ones I have encountered are more interested  
in _viewing_ things at a microscopic scale and not actually _working_  
at that level. I am suspicious that the more intense focus of the user  
entailed will exascerbate the disparities in the screen response to  
mouse movements.



For a dockable tracking view, I would suggest the following be  
considered for incorporation into its implementation:

1) The view always tracks the cursor when the cursor is over the image window.
2) That the display (outline, mask, etc) of the active tool within the  
tracking view be optional.
3) That a modifier key would switch mouse input scaling to match the  
zoom factor of the tracking view.
4) That when the modifier key is depressed, a rectangular outline  
appear in the image window indicating the bounds of the tracking view  
(and that the mouse scaling mentioned in "3)" is active.


P.S. My apologies if this appears twice on the list. My first attempt  
to submit it did not seem to work.
_

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

[Simon Budig]

Shlomi Fish ([EMAIL PROTECTED]) wrote:
> On Tuesday 20 March 2007, Simon Budig wrote:
> > Shlomi Fish ([EMAIL PROTECTED]) wrote:
> > > It took me 10 minutes to write.
> >
> > Oh wow. Is it just me or is this really a *lot* of time? Personally I'd
> > consider answering 6 "lazy questions" per hour a waste of time.
> 
> Well, a few notes:
> 
> 1. I didn't measure how much time it took me exactly. It was probably less 
> than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.

Ok, granted. I was just surprised that you'd seem to take this as
something not noteworthy.

> 2. I had to find a URL which more experienced developers would know by heart.

That is a misconception. I personally do know exactly one URL of the
website by heart: "http://www.gimp.org/";, ok, two:
"http://www.gimp.org/tutorials/";. Everything else is opening it
in the browser and search for the appropriate link (which in this case
is prominently in the menu structure). I do believe that this is the
same for all developers not actively working with the site itself.

> 3. 10 minutes is much less time consuming that writing a bug-fix or an 
> enhancement patch for the GIMP or for any other program. If it takes me 10 
> minutes to answer someone in a polite, friendly and encouraging way and he or 
> she later become an active developer, then I may have "wasted" 10 minutes, 
> but subsequently got hours and days of voluntary development in return.
> 
> Which alternative is better? You decide.

Well, if it were fun to answer these kind of obvious questions that two
minutes researching on the gimp homepage would have solved then you'd
have a real point. It is not fun though. To the contrary.

And frankly, we put a lot of effort into the source package to make it
as easy to compile as possible. I firmly believe that the quality of
GIMPs code is a lot better than that of a lot of other free software
projects, mostly because especially Mitch and Sven have very strict
guidelines for patches.

Then somebody comes and asks if Gimp is written in C/C++? I mean, come
on. That is like asking "I want to become a computer scientist. How does
a computer work?". It is just a painful question.

> (I'm not saying any people who is friendly will become so, but the fact is 
> we've deterred a great deal of potential contributors due to such behaviour.)

There are some easy things we can do to improve the communication with
other people, no doubt about this.

[further good points snipped]

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] Enhancement Proposal: Add a temporary magnifier

[Sven Neumann]

Hi,

On Tue, 2007-03-20 at 18:01 +0100, peter sikking wrote:

> I am not sure if Sven wants another feature request in bugzilla.
> If so I will write it.

Yes sure. We have discussed the feature here and now we should make a
useful bug report from it. That will help to remember the outcome of the
discussion and it might attract a developer who wants to work on this
feature.

I am not at all opposed to bug reports. I just doubt that it makes much
sense to keep adding enhancement requests without discussing them
beforehand. We currently have about 600 open bug reports, most of them
enhancement requests. For someone who isn't deeply involved with GIMP
development, it seems impossible to find out what would be important to
work on or even to get an idea of the direction that GIMP is taking.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

[Shlomi Fish]

On Tuesday 20 March 2007, Simon Budig wrote:
> Hi.
>
> Shlomi Fish ([EMAIL PROTECTED]) wrote:
> > It took me 10 minutes to write.
>
> Oh wow. Is it just me or is this really a *lot* of time? Personally I'd
> consider answering 6 "lazy questions" per hour a waste of time.
>

Well, a few notes:

1. I didn't measure how much time it took me exactly. It was probably less 
than 10 minutes. Something like 5 or 7 minutes. Hard for me to tell.

2. I had to find a URL which more experienced developers would know by heart.

3. 10 minutes is much less time consuming that writing a bug-fix or an 
enhancement patch for the GIMP or for any other program. If it takes me 10 
minutes to answer someone in a polite, friendly and encouraging way and he or 
she later become an active developer, then I may have "wasted" 10 minutes, 
but subsequently got hours and days of voluntary development in return.

Which alternative is better? You decide.

(I'm not saying any people who is friendly will become so, but the fact is 
we've deterred a great deal of potential contributors due to such behaviour.)

4. I believe it can be further reduced by creating an FAQ or a pharsebook of 
canned responses.

5. If you don't want to answer it - just skip to the next message, and let 
someone else answer it.

6. I believe many questions can be eliminated into the future by good human 
factors engineering. See for example:

http://www.joelonsoftware.com/articles/customerservice.html

Reading from it:

<
Almost every tech support problem has two solutions. The superficial and 
immediate solution is just to solve the customer’s problem. But when you 
think a little harder you can usually find a deeper solution: a way to 
prevent this particular problem from ever happening again.

Sometimes that means adding more intelligence to the software or the SETUP 
program; by now, our SETUP program is loaded with special case checks. 
Sometimes you just need to improve the wording of an error message. Sometimes 
the best you can come up with is a knowledge base article.

We treat each tech support call like the NTSB treats airliner crashes. Every 
time a plane crashes, they send out investigators, figure out what happened, 
and then figure out a new policy to prevent that particular problem from ever 
happening again. It’s worked so well for aviation safety that the very, very 
rare airliner crashes we still get in the US are always very unusual, one-off 
situations.
>

Speaking for experience, I got many emails for Freecell Solver ( 
http://fc-solve.berlios.de ), in which I was asked something along the lines 
of "I unpacked the zip file, double clicked the executable but all I get is 
an empty DOS BOX"). This happened because the executable just expected to 
receive standard input, and people who downloaded the Windows binary expected 
it would start a GUI. As a result, I added a small blurb to the standard 
error saying:


Reading the board from the standard input.
Type "fc-solve --help" for more usage information.
To cancel this message set the FREECELL_SOLVER_QUIET environment variable.


And as a result, I no longer received such messages, and was no longer 
bothered by them.[1] 

If someone asks a question times and again, then we can probably restructure 
the web-site, the program, the online help or whatever to prevent them from 
re-occuring.

> (Sorry for not replying to all of your mail - this just stuck out to me)
>

No problem. Although I would like to receive a reply from you or someone else.

Regards,

Shlomi Fish

[1] - It is possible that after reading this message, the people who 
downloaded and run the Windows binary just gave up on the program. But at 
least I was no longer bothered with it. 

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla

[Martin Nordholts]

Though, Inkscape I think seems to have succeeded better than both GIMP
and Krita (attatching new and prettier script version)

  Martin Nordholts



skrev:
> You're right, and I appologize for drawing hasty/wrong conclusions, my
> prejudices were wrong. Check out this awesome Ruby script though, it
> produces some rather interesting output nevertheless.
> 
>   Martin
> 
> 
> 
> :Manish Singh skrev:
>> On Tue, Mar 20, 2007 at 07:36:52PM +0100, Martin Nordholts wrote:
>>> GIMP is a widely used piece of software, if one compares to other pieces
>>> of FLOSS, there are often many more contributors at other, similar
>>> projects. Doesn't anyone find that strange?
>> I don't believe this is true. Can you back this up with some evidence?
>>
>> -Yosh
>>
> 
> 
> 
> 
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer



dev-community-test.rb
Description: application/ruby
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer