Re: new gfig [Re: [Gimp-developer] canvas background options]

2004-11-14 Thread David Neary
Hi Alan,

Alan Horkan wrote:
 On Sun, 14 Nov 2004, David Odin wrote:
and as I already said before, using the 2.0 version of gfig would mean
  to at least port the old version to the HIG standards,
 
 I was suggesting shipping the old unmodified version because it was more
 stable.

I just wanted to point out that the 2.0 API is completely
backwards compatible from 2.2 to 2.0. That means that you can
simply copy the old 2.0 gfig from lib/gimp/2.0/plug-ins to 
lib/gimp/2.2/plug-ins and it will work just fine. 

For a user installation, you might want to check, but I believe
that plug-ins in the $HOME/.gimp-2.2/plug-ins directory are
loaded before the global ones, so copying
lib/gimp/2.0/plug-ins/gfig there would do the same job for an
unprivileged user.

Personally I'm happy to see someone working on gfig. I wasn't
aware dindinx was working on it, and given the track record he's
built up, I'm sure that the plug-in will be very stable and much
more usable in short order.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread Alan Horkan

On Fri, 12 Nov 2004, Sven Neumann wrote:

 Date: Fri, 12 Nov 2004 23:42:42 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  'Useless discussion'.
 
  Thanks for the encouragement, with that attitude is it any wonder more
  people dont try and provide feedback and try and improve the gimp.

 Alan, the discussion became useless after the facts had been exchanged
 and several people explained you that the feature is indeed useful.
 That makes further discussions on this topic rather useless.

I am still hoping to get more information on how the feature is actually
use to try to better solve the problem rather than dwell on the
implementation any further.

I was unable to get to use the gimp 2.1 series until recently.  I cannot
provide feedback only when it suits your timetable.  When I pointed out
problems with 2.0 you gave out to me for not mentioning them during the
1.3 cycle so I am making my points before 2.2 is released.

 Especially during times of string and UI freeze.

All that means it that no changes will be made until after that freeze,
not that changes shouldn't be suggested.

(I really hope Gfig will be rolled back as the developer working on it has
previously suggested, it is definately not ready for 2.2)

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread Alan Horkan

On Sat, 13 Nov 2004, Simon Budig wrote:

 Date: Sat, 13 Nov 2004 00:41:18 +0100
 From: Simon Budig [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi all.

 Alan Horkan ([EMAIL PROTECTED]) wrote:
  On Fri, 12 Nov 2004, Sven Neumann wrote:
   Alan Horkan [EMAIL PROTECTED] writes:
Given my previous comments that is understandable and I think
discoverability is important but it doesn't make sense to have a
seperate menu item for every obscure feature and to me this is
most definately an obscure feature.
  
   It has been requested over and over again so there are certainly
   people who see a need for it.
 
  I never claimed some people wouldn't find it useful.

 You did however harp on the uselessness of this feature and advocate its
 removal. Despite numerous people supporting it. Just because you don't
 see the use of this feature that doesn't mean that it has none.

In hindsight I should have been more diplomatic, and I repeated the
comment excessively.

Perhaps I might have been less quick to complain if it had been only
one menu item that shows a dialog but it is not, it is a submenu
with several menu items and that seems a lot like clutter to me.
  
   It is a submenu, so it is only a single menu entry
 
  i dont follow that logic

 Simple: If a menu entry pops up a dialog or if a menu entry pops up a
 submenu is irrelevant for the menu itself. It is exactly one menu entry
 in the menu. It doesn't clutter less or more than a dialog.

My counterpoint is that even though a submenu means only one extra
menu in the parent menu it means another level and more items to
search through.  It doesn't make the specific feature any more
difficutl to use but more menu items overall can complicate the task of
finding anything.

  I'm not trying very hard to find it, finding problems is relatively easy
  finding solutions and finding the time to provide feedback in way you will
  actually listen to is what is time consuming.

 From my point of view the most things brought up by you are details.
 While I like attention to the detail I don't like that these things tend
 to need lots of discussion. The issue here is a perfect example:
 Configurability of the border color. This discussion should have been
 over when everybody except you agreed that it is useful. Suddenly about
 14 Mails pop up, 5 of these by you not understanding the point of the
 others. This does not help.

As we had started I had hoped to finish and move some way towards
improving the feature for those who want it and possibly making it less
obtrusive.  If the task is to compare an image with a Black Background, a
white Background and a Blue background, changing it one at time would be
slower than firing off a script that made copies and added a border in a
selection of colours (that is just a possible scenario, maybe there is no
room for improvement but if I'm not allowed to discuss it I'll never
find out).

I'll try and show more restraint and not drag out discussions longer in
future, I admit I got a little carried away.  In other mailing lists
normally only those interested in the thread would keep reading and
responding to it.

- Alan H.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread Sven Neumann
Hi,

Alan Horkan [EMAIL PROTECTED] writes:

 I was unable to get to use the gimp 2.1 series until recently.  I
 cannot provide feedback only when it suits your timetable.  When I
 pointed out problems with 2.0 you gave out to me for not mentioning
 them during the 1.3 cycle so I am making my points before 2.2 is
 released.

A couple of days before 2.2 is released and a long time after the
feature set and the user interface has been frozen. Not a very good
timing. But of course we are always open for suggestions.

Even though it seems rather useless, let me point you to bug #142996
which was the motivation for changing the canvas padding color user
interface in the first place. IMO the new way of doing it is a lot
better. You should also note that a lot of thought and work has gone
into this. Thus my comment about disrespect. I think that you are
ignoring how much attention has been given to the details here.

 (I really hope Gfig will be rolled back as the developer working on
 it has previously suggested, it is definately not ready for 2.2)

We have another developer working on it at the moment and he's
contributing his free time for the task of finishing the changes to
GFig that Bill started. This comment of yours (and you did the same
comment on gnomedesktop.org) is discouraging, nothing else. Please try
to avoid this in the future.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread Carol Spears
On Sat, Nov 13, 2004 at 09:03:28PM +, Alan Horkan wrote:
 On Sat, 13 Nov 2004, Simon Budig wrote:
  Alan Horkan ([EMAIL PROTECTED]) wrote:
   On Fri, 12 Nov 2004, Sven Neumann wrote:
Alan Horkan [EMAIL PROTECTED] writes:
 
 My counterpoint is that even though a submenu means only one extra
 menu in the parent menu it means another level and more items to
 search through.  It doesn't make the specific feature any more
 difficutl to use but more menu items overall can complicate the task of
 finding anything.
 
this is where gimp is at its best though.  searching endlessly through
the menus for one thing found many many more things i had needed before
or had heard of or would be hearing of soon.

if it makes sense to you out of the box, you are using software that is
beneath your ability.  you will soon be in a bleak and terrible life in
which everything you know has been done and is very predictible.

what is it exactly that you do not like about hunting for things in
software?

 I'll try and show more restraint and not drag out discussions longer in
 future, I admit I got a little carried away.  In other mailing lists
 normally only those interested in the thread would keep reading and
 responding to it.
 
hmm, yes.  this is really suspicious, isnt it?

carol

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-13 Thread David Odin
On Sat, Nov 13, 2004 at 08:51:26PM +, Alan Horkan wrote:
 
 (I really hope Gfig will be rolled back as the developer working on it has
 previously suggested, it is definately not ready for 2.2)
 
  Thanks for your help.  AFAIK, I'm the only one really working on gfig
for now.  It isn't ready for 2.2, but I'm doing my best to achieve
this.  If you have the skills to put a fully debugged, easy to read
and fully HIG compliant version of gfig (even a rolled back version, I
don't care), feel free to provide the sources to us.  Until I see this
code, I'll go on with debugging and polishing the existing version.

Regards,

 DindinX

-- 
[EMAIL PROTECTED]
i,d,j;main(n,v)char**v;{n=atoi(v[1]);d=atoi(v[2]);{int*r=alloca(5*d+10);char
*q=r+d+2;printf(%d/%d=%d,n,d,n/d);*q=46;*r=n%d;for(;id;i++){r[i+1]=(r[i]*
10)%d;q[i+1]=48+(r[i]*10)/d;for(j=0;ji+1;j++)if(r[i+1]==r[j])return*r=q[j+1
],q[j+1]=0,printf(%s,q),q[j+1]=*r,q[i+2]=0,printf([%s]\n,q+j+1);}}}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Alan Horkan

On Fri, 12 Nov 2004, Sven Neumann wrote:

 Date: Fri, 12 Nov 2004 15:39:58 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

 Hi,

 Alan Horkan [EMAIL PROTECTED] writes:

  I can understand how that would require you to change it regularly
  and why you might want a menu item for it.  How did you like how the
  feature was presented in 2.0 or were you unaware of it until it was
  given a prominant menu item?

 Hiding useful functionality in some obscure button with a right-click
 popup menu in the image corner is not really good user interface
 design and I am very much surprised that you don't consider this
 change an improvement.

Given my previous comments that is understandable and I think
discoverability is important but it doesn't make sense to have a seperate
menu item for every obscure feature and to me this is most definately an
obscure feature.  (most of the time I shrink wrap my images and dont even
see the canvas padding, if I wanted to regularly preview images against a
black background I would probably configure the Fullscreen mode for that
purpose)

Perhaps I might have been less quick to complain if it had been only one
menu item that shows a dialog but it is not, it is a submenu with several
menu items and that seems a lot like clutter to me.

 We also needed that space in the upper right corner for a more useful
 and less obscure feature that is also being offered in other
 applications: linking the image zoom ratio to the window size.

That does seem like a good idea of itself but I dont think it makes the
menu items for Canvas Padding idea any better than a workaround.

I'm surprised that enough users would be changing the setting often enough
to want to be able to set it on a once off per window basis, I would have
though that a single global preference would to override the toolkit
default would have been enough (which is as far as I can go towards
offering an alternative implementation).

Sincerely

Alan Horkan
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Jakub Friedl (lists)
 I'm surprised that enough users would be changing the setting often enough
 to want to be able to set it on a once off per window basis, I would have
 though that a single global preference would to override the toolkit
 default would have been enough

oh please no. or is the gimp supposed to be used only by beginners and
not by advanced users? if you do some more serious work you need often
to change the colour of the surrounding area. and you need it to do by
per image basis. if i edit images where colour is really important
(and this will be even more useful when gimp will be able to handle
colour management) i always set my gui theme to colours of neutral
grey so there is no colour distraction + i change this setting in the
gimp often to simulate different colour enviroments.

the feature is invaluable for an advanced user.

a month ago i was making three images to be placed on a wall, each of
them on different one, painted with different colour. i was painting
them at the same time (they were a series)
and i enjoyed the possibilty to see them all against the proper colour. 

BTW: if you feel that the gimp should be simplified as possible for
beginners, wouldnt be possible to keep advanced features visible for
advanced users but not for beginners? but not remove them completelly?
single option in preferences (or in gimprc file) which would enable
more advanced features which some consider as interface clutter but
others may need them?
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Alan Horkan

On Fri, 12 Nov 2004, Jakub Friedl (lists) wrote:

 Date: Fri, 12 Nov 2004 16:57:51 +0100
 From: Jakub Friedl (lists) [EMAIL PROTECTED]
 To: Alan Horkan [EMAIL PROTECTED],
  GDev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] canvas background options

  I'm surprised that enough users would be changing the setting often enough
  to want to be able to set it on a once off per window basis, I would have
  though that a single global preference would to override the toolkit
  default would have been enough

 oh please no. or is the gimp supposed to be used only by beginners and
 not by advanced users?

That line of reasoning can be used to justify adding a whole lot of crud
to the gimp that only really benefits the advanced users.  if anything
recent development has been removing little used plugins to reduce the
maintainance burden.

the gimp is the de facto standard for image editing on Linux, FreeBSD,
Solaris, and I'm sure a few others.  I there hardly any other piece of
graphics software as likely to be available as the gimp.

As such is extremely important to cater to ordinary users.

I don't want to make the gimp into something that advanced users cannot
use quickly and efficiently either, but an uncluttered streamlined user
interface should be of benefit to everyone.

I wish you would have resited the urge to overreact, all this is just
dicussion and although I would prefer not to have the Canvas Padding
feature I do not think my suggestions have yet been convincing enough.

 a month ago i was making three images to be placed on a wall, each of
 them on different one, painted with different colour. i was painting
 them at the same time (they were a series)
 and i enjoyed the possibilty to see them all against the proper colour.

I'm still convinced it is a minority feature and although it may be useful
I'm not convinced it is useful enough for most users to deserve such
prominant location in the menus.

Gimp 2.2 seems to be largely decided, and it is unlikely that my
suggestion would be taken on board until after 2.2 has been released.

 BTW: if you feel that the gimp should be simplified as possible for
 beginners,

I believe it should be simplified for everyone, most usability
improvements are optimisation of a different kind and just as
accessibility benifts more than just the disabled so too should good
usability benfit everyone.

I'm not arrogant enough to claim I'm an expert, but I thought I should be
able to discuss the change before 2.2 and if I didn't do it now I'd
probably be berated for not having mentioned it sooner.

 wouldnt be possible to keep advanced features visible for advanced users
 but not for beginners? but not remove them completelly? single option in
 preferences (or in gimprc file) which would enable more advanced
 features which some consider as interface clutter but others may need
 them?

Did you use Nautilus when it had a Normal mode and an Advanced mode?
It was a disaster because most users wanted one or two of the supposedly
Advanced features which meant turing on a whole lot of other advanced
features.

It is better to think of the task and the results you are trying to
achieve and see if there is a way to stream line the process.

I do not doubt that it is useful for you to have a way to easily compare
your image against various backgrounds.

What I am asking is if the current implementation is really the best way
to provide that feature?

You have made it clear that you want to be able to set a different
background colour for each image.  Do you set different colours for
different views of the same image?

If so might it not be beter even better to reorganise this functionality
in a way that allowed you to more quickly preview an image with various
different background rather than having to choose a different back colour
each time you wanted to make your comparisions.

If you describe in more detail how exactly you go about your work I might
be able to refine my suggestions.

I'm trying to make things easier for _everyone_ including you :)

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Sven Neumann
Hi,

Alan Horkan [EMAIL PROTECTED] writes:

 Given my previous comments that is understandable and I think
 discoverability is important but it doesn't make sense to have a seperate
 menu item for every obscure feature and to me this is most definately an
 obscure feature.

It has been requested over and over again so there are certainly
people who see a need for it.

 Perhaps I might have been less quick to complain if it had been only
 one menu item that shows a dialog but it is not, it is a submenu
 with several menu items and that seems a lot like clutter to me.

It is a submenu, so it is only a single menu entry and thus certainly
not clutter. It would have been clutter to use a dialog for something
that can be easily done using a small submenu.

Can we please stop this useless discussion here? I get the impression
that you are trying very hard to find something to criticise. Why do
you have to show so much disrespect for other people's work?


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] canvas background options

2004-11-12 Thread Simon Budig
Hi all.

Alan Horkan ([EMAIL PROTECTED]) wrote:
 On Fri, 12 Nov 2004, Sven Neumann wrote:
  Alan Horkan [EMAIL PROTECTED] writes:
   Given my previous comments that is understandable and I think
   discoverability is important but it doesn't make sense to have a
   seperate menu item for every obscure feature and to me this is
   most definately an obscure feature.
 
  It has been requested over and over again so there are certainly
  people who see a need for it.
 
 I never claimed some people wouldn't find it useful.

You did however harp on the uselessness of this feature and advocate its
removal. Despite numerous people supporting it. Just because you don't
see the use of this feature that doesn't mean that it has none.

   Perhaps I might have been less quick to complain if it had been only
   one menu item that shows a dialog but it is not, it is a submenu
   with several menu items and that seems a lot like clutter to me.
 
  It is a submenu, so it is only a single menu entry
 
 i dont follow that logic

Simple: If a menu entry pops up a dialog or if a menu entry pops up a
submenu is irrelevant for the menu itself. It is exactly one menu entry
in the menu. It doesn't clutter less or more than a dialog.

  and thus certainly not clutter. It would have been clutter to use a
  dialog for something that can be easily done using a small submenu.
 
 i think a small dialog with all the options in one place would not be any
 worse than the current setup

It would hamper the speed to switch between different settings
(menu-selection plus two clicks until you get your desired option  vs.
one menu-selection) and thus would cause inconvenience.

There is no advantage of a dialog. At least I don't see any.

Ok, the rest of the Mail are ramblings about discussions and some
personal remarks, mostly (but not exclusively) targeted at Alan.
I decided to post this into the public because I hope that it might help
to avoid personal incidents like this in the future.

  Can we please stop this useless discussion here?
 'Useless discussion'.

Sure useless. Many people did state that they like that feature. So far
you're the only one who doesn't like it and wants to change it.
Each party has stated its position, there is nothing to discuss unless
some new facts come into the game. So far there aren't any and
prolonging the thread with no arguments doesn't help.

[...]
  I get the impression that you are trying very hard to find something to
  criticise.
 
 I'm not trying very hard to find it, finding problems is relatively easy
 finding solutions and finding the time to provide feedback in way you will
 actually listen to is what is time consuming.

From my point of view the most things brought up by you are details.
While I like attention to the detail I don't like that these things tend
to need lots of discussion. The issue here is a perfect example:
Configurability of the border color. This discussion should have been
over when everybody except you agreed that it is useful. Suddenly about
14 Mails pop up, 5 of these by you not understanding the point of the
others. This does not help.

[...]
 What am trying hard to do is discuss ideas and find ways to improve things
 but you seem unwilling to tolerate polite and resonable discussion,
 perhaps you expect ideas to come out of nowhere fully formed or
 implementations to be just right first time.

Right now you are discussing a feature you don't use with people who
like it. You make a big issue of something that is a non-issue for the
other participants. An important part of a polite and reasonable
discussion is to know when to stop. Sorry, you missed that point.

  Why do you have to show so much disrespect for other people's work?

Ok, after battering on Alan here's one for Sven: I hate it when you pull
out the Disrespect-bat. IMO it is a Totschlagargument and not very
helpful. I don't think that exchanging arguments Gimp-related things
shows disrespect on the developers. To the contrary: Caring about
aspects of the GIMP is a way to show respect. And when you think that a
discussion wastes your time, ignore it. Pointing at the opponent and
put him in bad light is not helpful for the discussion and it does not
even help to stop it.

It however helps to prevent future discussions started by people who are
more shy but might have brilliant ideas. Pity.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] canvas background options

2004-11-12 Thread Laxminarayan Kamath
-- Forwarded message --
From: Laxminarayan Kamath [EMAIL PROTECTED]
Date: Sat, 13 Nov 2004 12:34:51 +0530
Subject: Re: [Gimp-developer] canvas background options
To: David Odin [EMAIL PROTECTED]


On Fri, 12 Nov 2004 01:02:31 +0100, David Odin [EMAIL PROTECTED] wrote:
   Yes, this feature is important to me at least.  It is important to
 have a dark surrounding around a dark image and a light one around a
 light image, so you can judge the contrast better.
  Regards,
  DindinX

Hey, Then y not automatically set it to the average of the border upon
loading of an image?
But some images need the average of  whole image, where as some need
one with hoghest  saturatiuon, another might need the least
saturation. what we do is set one of them automatically, say the
average of the border and the rest of the results be shown as a
choice. and at the end of the choice,  will be the cutom color
chooser.

Whether  to do this automatically or not can be added in pref dialog
--
Laxminarayan Kamath Ammembal
MithraKoota, Bhoja Rao Lane,
Mangalore 575003
(+91) 9845 061385
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
www.geocities.com/kamathln
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer