On Tue, Jun 21, 2005 at 07:18:25PM -0400, Nathan Summers wrote:
> On 6/21/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> >         include a menu entry for each of the gimp script powertools:
> >             the browsers
> >             the consoles
> >             the servers
> I see little reason why these shouldn't be a subcategory of the other
> dialogs.  The name "Development" was suggested.
the word "Development" was frightening to me.  i stayed a respectful
distance away from it for probably too long.  scripting gimp is easy and
somewhat empowering to me (only on my computer so far, it would be nice
to see some reflection of this feeling in my real life).  i found that
there was a similar situation involving the file named "HACKING" in the
cvs source.  this file contained helpful and perhaps necessary
information, however there seemed to be a gender related bias towards
looking at it.

and equally frightening name "Personalization" is also not a good word,
but it comes closer to what scripting gimp is like for me.  actually,
the thing that is wrong with this name is that it overlaps with the
meaning of "Preferences".  "Authoring" misses both marks, while perhaps
hitting a couple of marcs at the same time.  "Diving"?  "Dive In" is
probably more to the point of what actually happens when you are of the
mind to make gimp work a certain way and tackle this need with

"Development" as a word should be used (both ways) more respectfully
than is fun, or educational, or attractive to the larger group of people
who can use this stuff and grasp how to use it.

> >             potentially helpful non-gimp urls
> That opens another can of worms, but to be brief, I like the idea of
> having such urls either being redirects from the gimp website, or
> dynamically updated every gimp startup.
the best argument i heard against non-gimp urls being made available as
the gimp urls are now is maintenance.  can of worms is another
interesting argument against this.  i find the python library reference
extremely useful when i am scripting.  i dont need to get it through
gimp though.  both the perl and script-fu urls i have looked at scare
the beegeebies out of me.

> > i personally would not mind keeping Kevi1 busy with changes to Tiny-fu
> > for a while
> Kevi? is certainly not the only one qualifed to change the locations
> the scripts register under.  It's actually a trivial change for
> anyone.
no, but he has been willing.  the not trivial portion of the change is
the number of scripts that will need it.  

> >, however, i am uncomfortable with the limited view i have
> > had of the menu reorganization.  my completely unresearched opinion was
> > formed while seeing that it is being handled by people who have not
> > actually experienced the whole gimp eh, experience.  i also would be one
> > of these people.
> Well, no one has experienced all of the "gimp experience."  That's
> what good old fashioned kibitzing is for.
inspite of the very very not fun life changes that seemed to be
triggered when i worked on another wiki, part of the reason for this
thread was so that i could take the opinions of the developers who know
what is going on, who might have something left to lose by volunteering
at the gimp wiki.  unless there is a reason that everyone should lose
their life, their stuff and their little little place they carved out
for themselves.

> >  i can at least see that by the time i started to use
> > gimp, everything that appeared in Xtns were plug-ins that did not need
> > an image to start with. 
> Not technically true, as script-fu scripts are implemented through an
> extension, not a plug-in, but this only reinforces the point that no
> one knows/cares about the distinction.
well, it is nice to start weird and perhaps not so well maintained
scripts from somewhere not File.  it is not a necessity, however, i know
the lack of maintenance feeling i get is only gotten from when i use
anything in Xtns.  scripts that do not run nicely with the defaults
(script-fu fontmap was like that (i have too many fonts installed)) and
scripts that will cough up a DEPRECATED warning: i feel better when this
happens from Xtns--> and not from File-->

> > fixing the problem with different types of
> > scripts that do the same job in Xtns where it is much more of a problem
> > will help everyone with the Image menu which has a few instances of this
> > but not as many.
> My suggestion is that Xtns menu items that create images should be
> called something like File|New Generated Image and that the rest
> should be merged with the other dialogs, ether as File|Dialogs or as a
> new toplevel Dialogs menu item.
if new users are the concern, i have found that one of the biggest
problem that people who are new to computer graphics has is the lack of
understanding about what size image you need to have for the different
jobs that graphics are being used for.  meaning, they want to print
their little 125x75pixel icon of bart simpson (for example) as a

my idea was to keep the logo generating scripts (for example) in Xtns
and to modify them to register with sane defaults in menues created for
the different resolution needs.  "new user" to some means people who
were using other software applications and to others it means people who
are learning how graphics work on images for the first time.  the more
difficult of the "new users" would be those who can be defined with both
of these definitions.

thanks for your reply Nathan,

Gimp-developer mailing list

Reply via email to