is this correct: when 1.4 is released, gegl is expected to be ready so work
can begin on gimp-2.0.
if so, when? (in relative sense, ie. which gimp 1.3.x version will be the
version just before 1.4?)
also, i have a proposition for a simple gui enhancement which could
drastically boost speed of access to many things and usefulness of
accelerator keys. however, while it is *simple*, it is comparitively large in
scope (every registered dialog eg colorselector, layers, tool options would
require an individual accel-path added, and gtk menu code would require
enhancements). is this something i should make a patch for, or something that
could be added to the proposals/ in gimp2/ cvs?
essentially it would enhance menu accels so you could share specific
shortcuts, eg, sit in the color selector picking colors and hitting 'a' to
add them to the palette.
here is a paste of the doc i wrote:
++++ Shared keyboard shortcuts - part gimp, part gtk ++++
currently, keyboard shortcuts only work in their specific context.
having shortcuts that are shared between more than one context (still owned by
only one) would help greatly. for instance palette construction would be much
much quicker if i could assign a shortcut to <palette editor>'add' and
share that with the colorpicker, so i could eg. pick color, 'a', pick
color,'a' until the palette is finished. gradient creation could be
speeded up similarly (stack up colors in the 'save to' slots, then use the
saved colors
to create a large chunk of gradient quickly).
. likely format for shared shortcuts would be:
"(gtk-shared-accel-path
<ColorEditor,GradientEditor,PaletteEditor><PaletteEditor>/New Color)
(note that ColorEditor gets its own accel group, as would every
selection dialog eg Brushes,Gradients..)
so you can share key-accels for specific menu items rather than sharing
the whole class. a shared accel would require the accel being shared to
be already defined. this can be done by writing shared accels to menurc
last.
making the accels visible would mean adding an item to the menu, like
"(PaletteEditor/New Color)". note the brackets.
gtk would show the shortcut like this:
"(a)" rather than "a", to denote that you must go to, in this case, the
palette editor, if you want to change the key combination for that accel.
how to interface with that?
'delete' to remove the current context from the list of user-contexts
for a shared accel.
adding would require an additional menu item at the bottom of the
menu, like an inversion of the 'tearoff' menu item, on which you could
press 'insert' to add a shared accel or add current context to the users
of an existing shared-accel.
making the accels visible would mean adding an item to the menu, like
"(PaletteEditor/New Color)". gtk would show the shortcut like this:
"(a)" rather than "a", to denote that you must go to, in this case, the
palette editor, if you want to change the key combination for that accel.
(eof)
'how to interface with that' can hopefully be improved upon.
i also have a doc about weighting subsampling and optionally disabling
subsampling in a clean way. (attached -it's short)
i have some others (eg. slight colorselector interface cleanup) that are less
certain.
anyway.. what should i best do with these?
option to disable sub-pixel positioning , that is, force all coordinates for
drawing operations to be exactly centered in each pixel.
this greatly improves the smudge and clone tools, which ideally operate on a very
specifically defined area.
weighting for subsampling: currently, drawing diagonal lines with a
1-pixel brush gives the impression of lines that are apparently 1.5
pixels thick. the weight value would effect the apparent thickness(AT), in
other words, how optimistic the subsampling is about how much of a pixel
falls into an area.
algorithymically, it would probably be a multiplication factor applied
to pixels that are not wholly 'inside the area of the brush' (pixels at
the edge of a brush that are getting subsampled)
subsampled pixels that are at the edge could be found by comparing their subsampled
opacity
with their original opacity.
(ideally:
weight = 0 produces AT of 1,
weight = 0.5 produces current AT of 1.5
weight = 0.999999 produces AT of 1.999999)
this would effect the sharpness and apparent thickness of the edges of most lines
drawn with
any brush. 90 degree lines drawn via shift-click would be unaffected
(no subsampling to do).
(for gimp-2.0)
hard edge should be a toggle for paintbrush (brushing with ink is hard-edged)
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
