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)