Re: Icons in L&C dialog (and elsewhere)
Tuomas Kuosmanen <[EMAIL PROTECTED]> writes: > +--- > | Addition > | Subtract > | Lighten Only <- do these differ from the above ones > | Darken Only <- (addition & subtract) ? > | Value > +--- Yes. For addition, new_color = old_color + paint_color, while for lighten, new_color = max(old_color, paint_color) -- How to eff the ineffable?
Re: Icons in L&C dialog (and elsewhere)
On Mon, 25 Oct 1999, Seth Burgess wrote: > * Tuomas Kuosmanen ([EMAIL PROTECTED]) [991025 12:20]: > > > I was thinking slightly different on the separations: > + > | Normal > + > | Multiply (Burn) 1) > | Divide (Dodge) > | Add > | Subtract > +--- > | Color 2) > | Hue > | Saturation > | Value > +- > | Difference > | Overlay > | Screen > +-- > | Lighten Only 3) > | Darken Only > +-- > | Behind > | Disolve > +-- > > My reasoning - > > 1) Keep basic arithmetic together - maybe this is the engineer in me > though. Kinda bad that its not possible to group alphabetically and > keep sensible order though. Also move those to the top since they're > the most basic. > > 2) Any user that knows Hue or Saturation will look for Value > in the same area > > 3) Not sure what I was thinking :) Maybe they should go with Color/HSV > instead. This sounds good. Now to find someone to actually implement this? :) How do you add separators to menus? Tig .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: Icons in L&C dialog (and elsewhere)
Hello Quite right "stop" is not a good solution. There are as Sven says several tasks todo after a "freeze". Cheers Olof PS: Yes it's quite annoying for a writer when the UI or functionality changes. But thats life and I assume that we all in the same situation. On Mon, 25 Oct 1999, Sven Neumann wrote: > Heh, this thread turns out to be some sort of Gimp-book authors meeting, so I > should probably throw my Euro 0.02 in here... > > IMHO cleaning up the user interface is one of the most important things that > have to be done after a feature freeze. See it like this: people have been > throwing nifty features, new plug-ins and tools into The Gimp for over a year > now. You can't just declare "Stop" and then release that. Icons, menus, > dialog layouts, everything has to be rethought and changed if necessary. This > is going to happen now! Only it has be carefully discussed what has to be > changed and in what way... > > > Salut, Sven > (Who is working on the update for "Gimp kurz und gut" right now) > > > PS: Tigert, I like the new icons! What do you think about reordering them so > that Duplicate comes next to New? > >
Re: high dynamic range images
On Mon, 25 Oct 1999 [EMAIL PROTECTED] wrote: > > >On Mon, 25 Oct 1999 15:15:37 -0500, Kelly Lynn Martin wrote: > > > It's alive and well, but rather seriously divergent from the head > > branch. Merging the two would be a substantial effort. > > Where might one learn more about its progress? The web pages that > link from the Gimp site seem pretty stale. Or at least old enough to > make one wonder if the effort is still ongoing. Is there a working > release? Would it be worth it to merge them though? I mean the current CVS gimp has so much nice stuff for graphics tablets and such, that it'd suck to leave the Hollywood branch without them? Tuomas .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
BUGREPORT: Rotate doesnt work
Hello. The new dialog for the transform tool is very cool. However the Image -> Transforms -> [Image|Layer] -> Rotate doesnt seem to work..? Maybe something broke along the road? Tig .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Hollywood Gimp
>>Wasn't this something the 'HOLLYWOOD' branch in cvs was fiddling >>with? Or did that branch wither and die? > >It's alive and well, but rather seriously divergent from the head >branch. Merging the two would be a substantial effort. I would like to have latest snap of CVS for it. Anyone? Yours, Juhana
Re: Script-Fu Error
On Fri, 22 Oct 99 19:33:20, Asbjoern Pettersen wrote:
>>
>>I 'cvs update'd again, recompiled, and everything works fine now. I can
>>even run plugins which use fonts! However, clicking twice on the font
>>button will still crash script-fu, although selecting a font and running
>>the script will not crash until the script is finished running and script
>>fu cleans up its widgets. This makes script-fu functional for me again,
>>even if I have to restart the Gimp every time I run a script that uses a
>>fontselector :)
>
>I've been debug on OS/2 version and it crash when the font dialog is destroyed.
>
>It's in function script_fu_cleanup_widgets()
>
> case SF_FONT:
> if (script->arg_values[i].sfa_font.dialog != NULL)
> {
>/* crash HERE !!*/
> gtk_widget_destroy (script->arg_values[i].sfa_font.dialog);
> script->arg_values[i].sfa_font.dialog = NULL;
> break;
>
>The dialog pointer is correct so there can be a bug in gtk_widget_destroy()
>for GTK 1.2.5/1.2.6
>
>If you comment the destroy call out it works normally!
>
>So far so good.
>
>Asbjoern
Dowload all software and compiled an IRIX version of gimp.
The bug is in GLIB's 1.2.6 gcache.c ! node is NULL !?
My patch is inside #if 1.
void
g_cache_remove (GCache *cache,
gpointer value)
{
GRealCache *rcache;
GCacheNode *node;
gpointer key;
g_return_if_fail (cache != NULL);
rcache = (GRealCache*) cache;
key = g_hash_table_lookup (rcache->value_table, value);
node = g_hash_table_lookup (rcache->key_table, key);
#if 1
/* patch for removing GIMP scrip-fu crash */
if (node == NULL)
return;
#endif
node->ref_count -= 1;
if (node->ref_count == 0)
{
g_hash_table_remove (rcache->value_table, value);
g_hash_table_remove (rcache->key_table, key);
(* rcache->key_destroy_func) (key);
(* rcache->value_destroy_func) (node->value);
g_cache_node_destroy (node);
}
}
***
* Asbjørn Pettersen Phone work: +47 77 66 08 91 *
* Kongsberg Spacetec a.s Phone home: +47 77674022 *
* Telefax:+47 77 65 58 59 *
* Prestvannveien 38 www:http://www.spacetec.no *
* N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] *
***
limited slider range
On Mon, Oct 25, 1999 at 08:43:48PM -0400, Zach Beane - MINT <[EMAIL PROTECTED]> wrote: > shortsighted. You never know who might be using something in a way you > didn't think of. Err on the side of freedom next time. Many sliders in the gimp also have a rather limited range (brush size max. 100 points for example). Just increasing the range is not sensible however. How about logarithmic sliders? These would allow us to increase the dynamic range drastically while not loosing accuracy. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: limited slider range
On Tue, Oct 26, 1999 at 05:12:02PM +0200, Marc Lehmann wrote: > On Mon, Oct 25, 1999 at 08:43:48PM -0400, Zach Beane - MINT <[EMAIL PROTECTED]> wrote: > > shortsighted. You never know who might be using something in a way > > you didn't think of. Err on the side of freedom next time. > > Many sliders in the gimp also have a rather limited range (brush > size max. 100 points for example). Yes, there are clearly many entirely arbitrary constants in the GIMP. > Just increasing the range is not sensible however. > > How about logarithmic sliders? These would allow us to increase the > dynamic range drastically while not loosing accuracy. In some cases this might make sense. An easier option in many cases is to put a spinbutton on the value of the slider, so you can set the value coarsely with the slider, and then tune it with the spinbutton arrows and/or by typing in the value. In general, I prefer to type in numbers on a binary scale instead of dragging a decimal slider. For example, I'd like to see the Opacity slider in the Layers dialog be a slider+spinbox with a range of 0..255. Maybe something n Preferences could let the user select whther you want ranges to be 0..100%, 0..255, or 0..FF. Perhaps there could be a GimpSliderSpinEntry widget that would let you right-click to select the base and linear/log/exp scale - and these settings could be saved in prefs. Just my silly $0.02. Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
Re: grid plugin
Hi Xach, > The real-life units in the grid plugin are nice. > > However, removing the ability to a) start with a negative offset b) exceed > the image size and c) remember the last used unit have rendered this plugin > completely useless for what I usually use it for. > > Removing options just for the sake of removing options is pretty > shortsighted. You never know who might be using something in a way you > didn't think of. Err on the side of freedom next time. > You know very well that the reason wasn't to remove options... I'm pretty sure there is no (visible) grid that can't be generated with the new interface. But I agree that it might be easier to specify a negative offset then to calculate the positive offset that leads to the same result. What do you think about this: offset range: -image ... +image size range: image ... 2*image where image means image_width or image_height respectively. I will also look if there's a reasonable way to make the plug-in remember the unit. Salut, Sven
Re: grid plugin
On Tue, Oct 26, 1999 at 09:24:42PM +0300, Sven Neumann wrote: [snip] > I'm pretty sure there is no (visible) grid that can't be generated with the > new interface. But I agree that it might be easier to specify a negative > offset then to calculate the positive offset that leads to the same result. I use it frequently to generate horizontal bars a few pixels apart. I don't want any vertical bars, so setting a -1 offset and making it image_width+2 spacing does the trick. > What do you think about this: > > offset range: -image ... +image >size range: image ... 2*image That should allow for my typical usage. Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: grid plugin
On Tue, Oct 26, 1999 at 07:56:01PM -0400, Zach Beane - MINT wrote: > On Tue, Oct 26, 1999 at 09:24:42PM +0300, Sven Neumann wrote: > [snip] > > I'm pretty sure there is no (visible) grid that can't be generated with the > > new interface. But I agree that it might be easier to specify a negative > > offset then to calculate the positive offset that leads to the same result. > > I use it frequently to generate horizontal bars a few pixels apart. I don't > want any vertical bars, so setting a -1 offset and making it image_width+2 > spacing does the trick. It sounds to me like horizontal/vertical line checkboxes are called for in this case. Maybe also a checkbox for vertices so you can make dot-grids, or even a size value for checkboxes so you can make cross-grids. Like this: .. | Grid | || | [x] Horizontal line: width [1 +-] spacing: [1 +-] colour [pick] | | [x] Vertical line: width [1 +-] spacing: [1 +-] colour [pick] | | [x] Intersections: length [1 +-] spacing: [0 +-] colour [pick] | || |[OK] [ Cancel ] | `' The checkboxes on the left toggle H/V/I on and off. The 'width' spinbox lets you pick the line width (or should it use the current brush?). The 'spacing' spinbox lets you set the distance between the lines. The colour is pretty self-explanatory. The 'length' for the Intersections would set the length of the arms of the crosses, and the 'spacing' would set how far out from the middle of the cross they started. So, with just Intersections checked, length=3 and spacing=2 you would get a grid of crosses like this, spaced apart by the H and V spacing amounts: # # # ### ### # # # Another $0.02 :) Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
Color Display Filters segfaults all over the place
Like hitting 'Add', 'Down' etc...
/Tomas - too tired to debug right now 8/
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
Re: BUGREPORT: Rotate doesnt work
On Tue, Oct 26, 1999 at 12:32:24AM -0700, Tuomas Kuosmanen <[EMAIL PROTECTED]> wrote: > > Hello. > > The new dialog for the transform tool is very cool. However the Image -> > Transforms -> [Image|Layer] -> Rotate doesnt seem to work..? Maybe > something broke along the road? And when I call plug_in_rotate(...,3,0) directly the plug-in segfaults (I was told that the gcc benchmark result diagrams are broken, and this was the reason ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
PDB_Interface Changes
Hello to all GIMP developers.
If anyone changes or removes an
existing PDB-Interface
there are 2 things that should be done:
1) please check if the Interface is
alreay used in a Plugin.
(the plug-ins Directory of the
standard distribution should be checked)
On Unix Systems this can be done
with one find command like this:
cd /plug-ins
find . -type f -exec grep -l "gimp_convert_indexed" {} /dev/null \;
./perl/examples/Create_Images
./perl/examples/homepage-logo.pl
./perl/examples/image_tile
./perl/examples/prep4gif.pl
./gap/gap_range_ops.o
./gap/gap_range_ops.c
./gap/.libs/gap_plugins
2) send an e-mail to the Plugin Author.
The e-mail should inform the Author
about the Changes, and if you have
already changed the Plug-In or not.
(the Authors's e-mail Adress is
usually found in the Parameters
of gimp_install_procedure)
Please help to keep all the PlugIns working.
Wolfgang Hofer <[EMAIL PROTECTED]>
Author of some GIMP-Plugins
HotBot - Search smarter.
http://www.hotbot.com
Re: PIX changes in Gimp CVS (fwd)
I mailed Michael Taylor to keep him up to speed with PIX changes (he's the original author) and in his reply he asked a question I can't answer on behalf of the whole devel group/posse/community/whatever... So, opinions - does the feeling about plug-in bloat apply to File filters? Can Michael's other plug-in (s) go into CVS? -- Forwarded message -- Date: Tue, 26 Oct 1999 10:10:58 -0400 From: Michael Taylor <[EMAIL PROTECTED]> To: Nick Lamb <[EMAIL PROTECTED]> Subject: Re: PIX changes in Gimp CVS [lots snipped] I don't know if you're the person to ask, but do you think anyone would object if I moved my other plug-in into the main repo? I got the feeling that people on the mailing think that there are too many plug-ins distributed with Gimp. I've been trying to get CVS up and running on my SGI in my spare cycles, but it's a pain to do through a firewall. Anyway, I get e-mails weekly from people who can't compile my TDI plug-in for various reasons and it would make my life easier if I could just move it so that they get it by default.
Re: limited slider range
On Tue, Oct 26, 1999 at 05:12:02PM +0200, Marc Lehmann wrote: > On Mon, Oct 25, 1999 at 08:43:48PM -0400, Zach Beane - MINT <[EMAIL PROTECTED]> wrote: > > shortsighted. You never know who might be using something in a way you > > didn't think of. Err on the side of freedom next time. > > Many sliders in the gimp also have a rather limited range (brush size > max. 100 points for example). > > Just increasing the range is not sensible however. > > How about logarithmic sliders? These would allow us to increase the > dynamic range drastically while not loosing accuracy. The Ink tool could also be larger, think 300 DPI poster stuff :) Though it might be slow, but someone might have a Quad X3on 600MHz Ph3ar B0x for gimping or something (no, that is not me :) 20 pixels is pretty small (on 300 dpi that means 1.69 millimeters) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Export function problems
I've been testing out Export to make sure it is idiot proof, and I have some problems to report: TIFF (and for the moment PNG too) can't handle INDEXED ALPHA, though they can handle either alone, they can't handle both at once. There's no way to reflect this in the Export API - either a way must be added, or there must be a workaround elsewhere... XBM will fail after export worked, because it inists on having precisely two colours. That's fair enough when you know what an XBM is, so I don't know if / how we should fix it. PAT doesn't seem to have been designed with alpha in mind. Is there a good reason to use alpha with PAT? Does Gimp even support it anywhere? Right now it Exports with CAN_HANDLE_ALPHA and the results are not good. Other than these, my tests all look great. There was no consensus about changes to the displayed availability of file formats, so I'm still thinking about that off-line. Nick.
Re: limited slider range
Thus spoke Tuomas Kuosmanen > The Ink tool could also be larger, think 300 DPI poster stuff :) Though > it might be slow, but someone might have a Quad X3on 600MHz Ph3ar B0x for > gimping or something (no, that is not me :) > > 20 pixels is pretty small (on 300 dpi that means 1.69 millimeters) Shouldn't these ranges be tied to the resolution setting? ie change the resolution and the ranges will update (well, maybe not for an open dialog, but perhaps the next time its opened). -- Michael J. Hammel | The Graphics Muse | The lyf so short, the craft so long to lerne. [EMAIL PROTECTED] | Chaucer http://www.graphics-muse.com
