On Tue, Jun 21, 2005 at 05:38:36PM -0700, Akkana Peck wrote:
> Nathan Summers writes:
> > On 6/21/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> > > different levels of artificial intelligence; are there opinions of ways
> > > to rearrange the Xtns portion of the menu system?
> Great topic. Personally I'd love to see the Script-Fu and Python
> entries go away, for the same reason as in the Filters menu:
> the user shouldn't have to know.
the one situation that i found this condition of gimp to be effective
for was to quickly figure out what was installed and what wasnt when 
helping people to debug scripts or install necessary scripts.

that usefulness is gone now.

> > >         people rearranging the menus now do not seem to see that Xtns
> > >         makes its own image and do not need to start with an image; even
> > >         though the logic is very clear to some.
> > 
> > The thing is that there are plenty of exceptions to that rule. 
> > File|Dialogs being a big source of stuff that doesn't need an image,
> File->Dialogs doesn't make a new image. I'm with Carol, most of the
> stuff in Xtns makes a new image, and should be grouped together
> accordingly.
thanks for agreeing!

> > >         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.
> Right. If it were up to me, I'd split Xtns into two menus:
> 1. Development (or something similar): all the entries that have to
> do with mechanics of the languages (including C). It would look like:
>    Module Manager
>    Plug-in Browser
>    Procedure Browser
>    Unit Editor
>    --------
>    Script-Fu Console...
>    Refresh Script-Fu
>    Start Script-Fu Server...
>    --------
>    Python-Fu Console...
>    Python-Fu Browser...
perhaps "Scripting" with submenus like that with the addition of:

Perl Server
Perl Console
Perl Browser

with the assumption that a perl console and browser can be written.

> 2. All the things that actually make new images. I don't know what
> to call this menu. Xtns or Misc or Generate (because it generates
> new images) or Create or New Images or ??  This would include all the
> submenus that are currently under Script-Fu, without any reference to
> the word "Script-Fu". Any Python scripts (or C plugins or anything else)
> that gets added would merge into these menus too.
i still find the idea of "Utility" very appealing.  especially when
considering where some scripts i wrote should go.  silly scripts that
generate web pages which will report what resources your gimp has access
to.  and plans i have for scripts that can apply parasites to groups of

i also think that grouping the other plug-ins that make new images by
resolution somehow would be most helpful to new users and not so
well-educated older users and converts.  use politically correct words
for this like "screen" and other words that define the media that images 
are used on.

"Web Page Themes" actually does do exactly as promised.

instead of Create or New Images, the menu entry that gimp-perl installs
that is called "Render" seems fitting.  and "Animation" which i am using
for my python animation scripts.  it has been nice to have this menu
there for this, i cannot imagine a better place to put it and do not
want to search through "Create" or "Render" to find them.  most of them
are more like "Alter Stacks".

> I'd lean toward making both these menus top-level menus in the toolbox
> window (so there would be four menus, not three), but that would cause
> space issues in verbose languages and large fonts, so alternately,
> I'd make Development a submenu (probably of File or File->Dialogs, not
> of Xtns/Generate/whatever, since the Development items do not create
> an image). It's more important that the New Image Creating stuff
> be easy to access than that Development is, because anyone
> developing scripts for gimp knows enough to use tear-offs, or
> set up key bindings, or somehow make it easier to get to the
> language tools.
i do not mind moving the scripting stuff.  i admit, i have grown fond of
Xtns and cringe when i think of this name changing.  i can see how
difficult it must be to translate, however.

> > Kevi? is certainly not the only one qualifed to change the locations
> > the scripts register under.  It's actually a trivial change for
> > anyone.
> I'd be happy to do the work if we reach consensus on what should
> be done.
i feel the same way, especially about the consensus part.  if it means
agreement the way it is being used here.

> > Well, no one has experienced all of the "gimp experience."  That's
> > what good old fashioned kibitzing is for.
> That's also what discussion on mailing lists, bugzilla and IRC are
> for. We still won't encompass the whole gimp experience, but at
> least by doing things in the open we'll have a chance of hearing
> from a range of people.
> > 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.
> I'd argue for that menu being a toplevel menu, so users are more
> likely to explore it.  There are some cool scripts in there.
> There's some reorganization that could usefully be done inside that
> menu as well. Buttons only has two items, Misc only has Sphere,
> Utils only has two items. How about moving those five items up to be
> directly visible in the Generate/Create menu?
> So it would look like this:
>   Logos>
>   Make Brush>
>   Patterns>
>   Web Page Themes>
>   -----------
>   Custom Gradient...
>   Font Map...
>   Round Button...
>   Simple Bevelled Button...
>   Sphere...
> Thoughts?
how about:
        Font Map
        Make Brush

actually, Make Brushes and Patterns could be updated to use different
defaults for the different resolution sizes as well -- patterns more so
than brushes.


than brushes.
Gimp-developer mailing list

Reply via email to