Re: grid plugin
Hi, > > > > 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 ] | > `' > Sounds like you are volunteering to hack this? Please feel free to do so! Otherwise I'll add the checkboxes when I find some free time and hope that everyone is happy. Xach, do we still need the extended ranges when there's a proper way to disable the grid in one orientation? Salut, Sven
data structure of pixel in Gimp-perl
Hi, there, I am using Gimp-Perl v1.083 to manipulate the pixel data of an image. What I am confusing about is the data structure of the packed pixel data. For example, I can run the following perl code: $region = $drawable->get->pixel_rgn (0,0, 100,100, 1,0); $pixel = $region->get_pixel (5,7); # fetches the pixel from (5|7) print $pixel; # outputs something like # [255, 127, 0], i.e. in # RGB format ;) But how can I modify the components of this $pixel? For example, modify it to [255,127,1]? I have tried to treat it as an array or an array reference, but I failed. Any help is greatly appreciated. Xiaodi
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 ;) Hmm, could you please try to make slightly more informative bug-reports... So far I don't even know which plug-in you mean. Tigert mentioned a new dialog for the transform tool. What new dialog are you referring too?? The "Transform Tool" is the rotate/scale/shear/perspective tool accessible from the toolbox, right? Then we have two rotate plug-ins: o Transforms->Rotate opens a dialog and should be seen as plug_in_rotate from the PDB. This is the plugin that is called "Rotate". o Transforms->[Image|Layer]->Rotate->[90|270] are all accessors to one plug-in which should be referred to as "Rotators". Now, after I have explained the naming scheme, could you please send in your bugreports again? Salut, Sven
Re: data structure of pixel in Gimp-perl
On Wed, Oct 27, 1999 at 10:23:17AM -0700, [EMAIL PROTECTED] wrote: > Hi, there, > I am using Gimp-Perl v1.083 to manipulate the pixel data of an image. While that version should work, I fixed a great many errors in PDL support since then, and there were also behavioural changes (like an extra dummy dimension for greyscale data) that make working with pixels easier, but breaks backwards compatibility. It would be a good idea to upgrade to 1.14. > What I am confusing about is the data structure of the packed pixel > data. For example, I can run the following perl code: > > > $region = $drawable->get->pixel_rgn (0,0, 100,100, 1,0); > $pixel = $region->get_pixel (5,7); # fetches the pixel from > (5|7) > print $pixel; # outputs something like ># [255, 127, 0], i.e. in ># RGB format ;) > > But how can I modify the components of this $pixel? For example, modify > it to [255,127,1]? The pixels look like arrays, but are, in fact, PDL objects (i.e. some kind of array ;) > I have tried to treat it as an array or an array reference, but I > failed. Any help is greatly appreciated. You can treat it as a vector (or an array of vectors for two-dimensional data), e.g.: $pixel = ($pixel + 100) / 2; $pixel = 255 * $pixel / max($pixel); will do the obvious scalar arithmetic to the pixel (or pixels). You can use "at" and "set" to get or set subvalues, but this is (of course) slow if you do it often. I recommend that you check the PDL::Impatient manpage for a quick overview (just enter "perldoc PDL::Impatient" at the prompt). If any questions remain then just ask me ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: grid plugin
Sven; On Wed, Oct 27, 1999 at 11:12:28AM +0300, Sven Neumann wrote: > > > 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 ] | > > `' > > Sounds like you are volunteering to hack this? Please feel free to > do so! > > Otherwise I'll add the checkboxes when I find some free time and > hope that everyone is happy. Xach, do we still need the extended > ranges when there's a proper way to disable the grid in one > orientation? Well all right. Time for me to join irc.gimp.org and start asking stupid questions. Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
Re: BUGREPORT: Rotate doesnt work
On Wed, Oct 27, 1999 at 01:02:41PM +0300, Sven Neumann wrote: > > 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 ;) > > Hmm, could you please try to make slightly more informative bug-reports... > > So far I don't even know which plug-in you mean. Tigert mentioned a new > dialog for the transform tool. What new dialog are you referring too?? > > The "Transform Tool" is the rotate/scale/shear/perspective tool accessible > from the toolbox, right? > > Then we have two rotate plug-ins: > o Transforms->Rotate opens a dialog and should be seen as plug_in_rotate > from the PDB. This is the plugin that is called "Rotate". > o Transforms->[Image|Layer]->Rotate->[90|270] are all accessors to one > plug-in which should be referred to as "Rotators". > > Now, after I have explained the naming scheme, could you please send in your > bugreports again? > > > Salut, Sven > Hi, I don't read in Tigert's mind, but I have the same exact problems. Here's how to reproduce the bug: Create a new image. Draw something in it. Use any "Rotators" you want -> nothing happens Hope this helps. -- [EMAIL PROTECTED] Telling the truth to people who misunderstand you is generally promoting a falsehood, isn't it? -- A. Hope
Re: limited slider range
> > 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). Using sliders for these things is wrong. You cannot specify things precisely and they have a limited range. These should be GtkSpinButtons with a *big* adjustment range instead. Federico
Re: limited slider range
On Wed, Oct 27, 1999 at 12:15:27PM -0400, Federico Mena Quintero wrote: > > > 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). > > Using sliders for these things is wrong. You cannot specify things > precisely and they have a limited range. These should be > GtkSpinButtons with a *big* adjustment range instead. Though sliders are nice to adjust when things dont have a 'enumerated' nature like "tilt sensitivity" - it is hard to justify what a setting of "35" does, but having a slider is easier since you can visualize the range easier.. But I am not really sure what the ideal solution would be.. For percentage-type stuff (0-1 values) sliders are good (like for opacity) Maybe the spinbutton would be ok after all, testing it in practice would give more ground to judge the stuff.. It's a lot about how you are used to doing different things and how long you have been using a feature.. Tig -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: limited slider range
On Wed, Oct 27, 1999 at 10:25:01AM -0700, Tuomas Kuosmanen wrote: > On Wed, Oct 27, 1999 at 12:15:27PM -0400, Federico Mena Quintero wrote: > > > > 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). > > > > Using sliders for these things is wrong. You cannot specify > > things precisely and they have a limited range. These should be > > GtkSpinButtons with a *big* adjustment range instead. > > Though sliders are nice to adjust when things dont have a > 'enumerated' nature like "tilt sensitivity" - it is hard to justify > what a setting of "35" does, but having a slider is easier since you > can visualize the range easier.. But I am not really sure what the > ideal solution would be.. For percentage-type stuff (0-1 values) > sliders are good (like for opacity) I personally would prefer to use the slider to get an idea of where I'm going then type a hexadecimal value from 0x00 to 0xFF to set the opacity. However, I know that it is especially important to accommodate normal humans who may not actually think in terms of numerical values. > Maybe the spinbutton would be ok after all, testing it in practice > would give more ground to judge the stuff.. It's a lot about how you > are used to doing different things and how long you have been using > a feature.. I know I'm repeating myself, but why not use _both_? In the case of the opacity slider, the number is displayed right beside it. Making this number a spinbutton would not take up very much more screen real estate and it would allow everyone to work with the value in the manner they prefer. I'd like to see more slider/spinbox combinations in the GIMP. The slider is great for figuring out the correct value but being able to tune it by typing in a number is essential for precision work. Cheers, Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
Re: limited slider range
> I know I'm repeating myself, but why not use _both_? In the case of > the opacity slider, the number is displayed right beside it. Making > this number a spinbutton would not take up very much more screen real > estate and it would allow everyone to work with the value in the > manner they prefer. > > I'd like to see more slider/spinbox combinations in the GIMP. The > slider is great for figuring out the correct value but being able > to tune it by typing in a number is essential for precision work. Why not use slider - input box combination? You can adjust the slider with keyboard, so the spinbutton is kinda unnecessary - or you can just insert a value there.. If we put there a slider _and_ a spinbutton, we need to beware of making the dialogs too large - not everyone has a 21" screen with high resolution, and the always-present problem is the screen estate that happens to be too small all the time (except when you are doing a 24x24 pixel gnome-stock icon :) Thoughts? I am open to correction and willing to learn new GUI things :) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: limited slider range
> Though sliders are nice to adjust when things dont have a 'enumerated' > nature like "tilt sensitivity" - it is hard to justify what a setting of > "35" does, but having a slider is easier since you can visualize the range > easier.. But I am not really sure what the ideal solution would be.. For > percentage-type stuff (0-1 values) sliders are good (like for opacity) Sliders are nice when you 1. Have a well-defined range, 2. Don't need much precision. If you do have a well-defined range *and* you need precision, you can have a slider next to an entry or spin button. If you do not have a well-defined range, you should use a plain entry. GtkAdjustments and spin buttons work OK if you set the range of the adjustment to something huge. You don't want to limit things like image sizes (except for file format limitations) or brush sizes. Federico
Re: limited slider range
On Wed, Oct 27, 1999 at 11:23:20AM -0700, Tuomas Kuosmanen wrote: > TomR wrote: > > I know I'm repeating myself, but why not use _both_? In the case > > of the opacity slider, the number is displayed right beside it. > > Making this number a spinbutton would not take up very much more > > screen real estate and it would allow everyone to work with the > > value in the manner they prefer. > > > > I'd like to see more slider/spinbox combinations in the GIMP. The > > slider is great for figuring out the correct value but being able > > to tune it by typing in a number is essential for precision work. > > Why not use slider - input box combination? You can adjust the > slider with keyboard, so the spinbutton is kinda unnecessary - or > you can just insert a value there.. That's a good point, but I find that doing fine adjustments with a spinbutton is easier than with a slider - especially if the slider's length varies with the size of the dialog box it's in. > If we put there a slider _and_ a spinbutton, we need to beware of > making the dialogs too large - not everyone has a 21" screen with > high resolution, and the always-present problem is the screen estate > that happens to be too small all the time (except when you are doing > a 24x24 pixel gnome-stock icon :) A spinbutton is not significantly bigger than a normal text entry, but you're right, these widgets do start to add up. Cheers, Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
Re: limited slider range
> A spinbutton is not significantly bigger than a normal text entry, but > you're right, these widgets do start to add up. If it gets tight, we could shrink the slider and make the dialog resizeable, so if one needs precision for the slider, he/she can make the dialog wider. Maybe try adding spinbuttons to the ink tool for example, and see how it feels..? Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: limited slider range
Thus spoke Federico Mena Quintero > Sliders are nice when you > > 1. Have a well-defined range, > 2. Don't need much precision. Exactly. > If you do have a well-defined range *and* you need precision, you can > have a slider next to an entry or spin button. Thats the traditional solution, but from a UI design perspective I've never really been happy with it. I saw dials implemented on an SGI once and thought that was a pretty good idea, since end users are familiar with them in the "real world". The problem remains how you make a dial context sensitive, where its range is variable depending on other configurations. BTW, does GNOME have a dial widget? I don't think GTK does, but maybe I've just not heard anyone talk about it. > If you do not have a well-defined range, you should use a plain > entry. GtkAdjustments and spin buttons work OK if you set the range > of the adjustment to something huge. You don't want to limit things > like image sizes (except for file format limitations) or brush sizes. In this case (although I've forgotten the specific case we're talking about) the range is defined, but varies according to the resolution setting. So its a question of whether this is considered "well defined" or not. To me, it is well defined. The input mechanism doesn't need to change, but the range allowed does. However, you do have the problem of added precision when the range changes from a 72DPI context to a 300DPI context. > X-Tigert-Header: Eek! > X-perience: what you needed right before obtaining it You guys crack me up. :-) -- Michael J. Hammel | "Life is like an ice cream cone. You can lick it The Graphics Muse | and enjoy it or just watch it melt away and turn [EMAIL PROTECTED] | all sticky." Jim Ignatowski (from "Taxi") http://www.graphics-muse.com
Re: limited slider range
Thus spoke [EMAIL PROTECTED] > That's a good point, but I find that doing fine adjustments with a > spinbutton is easier than with a slider - especially if the slider's > length varies with the size of the dialog box it's in. If an input mechanism, in this case the spin button, is to offer fine control for the input, and the range is large, then it also has to offer a high speed method for going through large ranges fast. This means that the button has two contexts - click for slow, press and hold to speed up. This isn't difficult to implement, but it *is* confusing to the user. I've done this on various other UI designs and have always had someone tell me that it was too hard to figure out how to use it. This is another reason I like dials - drag fast and spin the dial like a roulette wheel. Drag slow and fine tuning is possible. Such interaction is apparently more intuitive (at least to the people I've asked). But I guess thats somewhat useless info if dials aren't available. So, nevermind. :-) -- Michael J. Hammel | "I don't like people. They can't be easily The Graphics Muse | categorized, referenced or explained." [EMAIL PROTECTED] | Michael "Spooky" Hammel http://www.graphics-muse.com
Re: BUGREPORT: Rotate doesnt work
On Wed, Oct 27, 1999 at 01:02:41PM +0300, Sven Neumann <[EMAIL PROTECTED]> wrote: > > > > 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 ;) > > Hmm, could you please try to make slightly more informative bug-reports... > So far I don't even know which plug-in you mean. What additional information do you require?? > Now, after I have explained the naming scheme, could you please send in your > bugreports again? See above. In script-fu it is probably: plug-in-rotate something image drawable 3 0 -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: limited slider range
Tuomas Kuosmanen wrote: > > I know I'm repeating myself, but why not use _both_? In the case of > > the opacity slider, the number is displayed right beside it. Making > > this number a spinbutton would not take up very much more screen real > > estate and it would allow everyone to work with the value in the > > manner they prefer. > > > > I'd like to see more slider/spinbox combinations in the GIMP. The > > slider is great for figuring out the correct value but being able > > to tune it by typing in a number is essential for precision work. > > Why not use slider - input box combination? You can adjust the slider with > keyboard, so the spinbutton is kinda unnecessary - or you can just insert a > value there.. > > If we put there a slider _and_ a spinbutton, we need to beware of making the > dialogs too large - not everyone has a 21" screen with high resolution, and > the always-present problem is the screen estate that happens to be too small > all the time (except when you are doing a 24x24 pixel gnome-stock icon :) > > Thoughts? I am open to correction and willing to learn new GUI things :) > > Tuomas > > -- > > .---( t i g e r t @ g i m p . o r g )---. > | some stuff at http://tigert.gimp.org/ | > `---' While we are on the topic of sliders / spinbuttons / entry widgets, I'd like to point out that it would be nice if the same discussion could be applied to the l&c&p dialog where transparency in the layer is concerned. I like the slider, but it would be very nice to have the number next to it (the transparency percent) be interactive via a text entry blank thing. It would be a Good Thing [tm], imo. PS: I like having a slider better than a spinbutton on the ink tool because you can slide it all the way to the max or min w/o having to incriment slowly one-by-one (like with a spinner) -- Garrett LeSage - Linux.com Art Director [EMAIL PROTECTED] - http://linux.com/
Re: limited slider range
> > PS: I like having a slider better than a spinbutton on the ink tool because > you can slide it all the way to the max or min w/o having to incriment slowly > one-by-one (like with a spinner) > I don't like the idea to enlarge the ideas even more, but what from what I read from this thread I have the impression that a lot of you are not aware of the capabilities of the GTK+ spinbutton, so here comes a short tutorial... Press left mouse button on the arrow to change by a small amount (this is usally 1 or 0.1) Hold left button on the arrow to increase the speed the spinner is updating. Press middle mouse button on the arrow to change by page_size (this is usually 10 or 1) Press right mouse button to go the max/min respectively Use the cursor up|down keys to go up or down by the small amount that matches the left mouse button click. Use the PageUp / PageDown keys to go up or down by the page_size that matches the middle mouse button click. Use Ctrl with the PageUp / PageDown keys to go the max/min respectively Salut, Sven
Re: BUGREPORT: Rotate doesnt work
Hi, > > What additional information do you require?? > > See above. In script-fu it is probably: > > plug-in-rotate something image drawable 3 0 > Well, it seems that someone changed the calls to gimp_drawable_is_layer() in all plug-ins and forgot to change the PDB calls... Salut, Sven
Re: BUGREPORT: Rotate doesnt work
On Thu, Oct 28, 1999 at 12:08:11AM +0300, Sven Neumann <[EMAIL PROTECTED]> wrote: > > > > plug-in-rotate something image drawable 3 0 > > > > Well, it seems that someone changed the calls to gimp_drawable_is_layer() > in all plug-ins and forgot to change the PDB calls... Hey, that was me ;) And it seems we now have a much better error management !!! -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: limited slider range
>> > Using sliders for these things is wrong. You cannot specify >> > things precisely and they have a limited range. These should be >> > GtkSpinButtons with a *big* adjustment range instead. >> Though sliders are nice to adjust when things dont have a >> 'enumerated' nature like "tilt sensitivity" - it is hard to justify >> what a setting of "35" does, but having a slider is easier since you >> can visualize the range easier.. But I am not really sure what the >> ideal solution would be.. For percentage-type stuff (0-1 values) >> sliders are good (like for opacity) >I personally would prefer to use the slider to get an idea of where >I'm going then type a hexadecimal value from 0x00 to 0xFF to set the >opacity. However, I know that it is especially important to >accommodate normal humans who may not actually think in terms of >numerical values. Not everyone knows hexadecimal, so make that selectable where possible (0 - 1, 0 - 255, 0x00 - 0xFF, 0% - 100% could mean all the same). But the mix of slider and keyboard input (spinbutton or input box) is, IMHO, the way to go, because: - it has visual feedback - can be used in coarse way with mouse - can be used precissely with keyboard (input) / mouse (spin) >> Maybe the spinbutton would be ok after all, testing it in practice >> would give more ground to judge the stuff.. It's a lot about how you >> are used to doing different things and how long you have been using >> a feature.. >I know I'm repeating myself, but why not use _both_? In the case of >the opacity slider, the number is displayed right beside it. Making >this number a spinbutton would not take up very much more screen real >estate and it would allow everyone to work with the value in the >manner they prefer. And will make 50% a real 50% and not vary with the size of the slider making it 49.7 most of times (just an example, maybe typical is 49.9). >I'd like to see more slider/spinbox combinations in the GIMP. The >slider is great for figuring out the correct value but being able >to tune it by typing in a number is essential for precision work. Maybe right click slider to launch a dialog where you input precise numbers? by keyboard It also could show max and min values, or recommended values. The number is there in most of the sliders, so I see no serious problem about space: click number, dialog appears. Or convert number to input area. GSR
Update to the print plugin
I discovered a fairly nasty bug in 6-color mode in which there was a discontinuity at the point that 6-color mode kicked in. Depending upon the orientation of the gradient, the effect is either a dark line of the color in question (cyan or magenta) or a white line. I had thought it was a print head misalignment until I decided to take a closer look. There was a related bug in 4-color mode; the symptoms probably would be similar. In either event, there's a new version on my web site: http://www.tiac.net/users/rlk/print.tar.gz. As for the issues I identified in my last message, here is how I propose to handle them: Notable issues with the current code (I consider all of these minor). 1) print.c is a real mess right now. All the settings-handling code is ad hoc and very ugly, and there's a lot of knowledge scattered about the code. Not directly necessary to fix for release (unless someone wants to :-) ). However, cleaning this up may make fixing the save/load code easier to fix. 2) As noted, the settings save/load code isn't perfect. It's OK for beta (or development), but not really for a release. Should be fixed for release. 3) Printing at 360 dpi (on the Stylus Photo) yields slightly reddish grays. I'm not quite sure what to make of it. 360 dpi is proofing resolution, and I'm not all that worried about perfection there (I'm more concerned about a much smaller greenish or cyan cast at 720 dpi, and a possible slight blue-magenta cast in lighter tones). I don't have a strong opinion on this. I consider 360 dpi mode to be purely for proofing and I'm not overly concerned with details, but on the other hand if people find the color cast too objectionable it should be fixed. 4) The K->CMY code is distinctly tuned for the Stylus Photo EX right now. Sorry, I don't have another color printer to play with. This should be addressed, but it won't be unless we get testers. 5) The Stylus Photo printing has become very slow for some reason (at least at 720 dpi). On the other hand, the microweave-induced banding has entirely vanished, yielding much (arguably spectacularly) better quality. I'm not positive exactly what did this, but it's not at the top of my list of priorities to "fix". If it takes 30 minutes to print a really high quality full-page print that doesn't seem so bad. Not to be fixed, since this "problem" improves output quality substantially in the highest quality output mode. 6) Entirely get rid of the 8-bit rendering when the 16-bit rendering is tested for all of the various rendering functions on a reasonable variety of hardware. Remove this code at release. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: limited slider range
> > If you do have a well-defined range *and* you need precision, you can > > have a slider next to an entry or spin button. > > Thats the traditional solution, but from a UI design perspective I've never > really been happy with it. I saw dials implemented on an SGI once and > thought that was a pretty good idea, since end users are familiar with them > in the "real world". The problem remains how you make a dial context > sensitive, where its range is variable depending on other configurations. > > BTW, does GNOME have a dial widget? I don't think GTK does, but maybe I've > just not heard anyone talk about it. Dials are kinda large though. You can fit a lot more sliders and spinbuttons than dials to Ink tool's options.. I am not sure if we have a dial, I think some gtk app might have had such widget somewhere.. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: limited slider range
> While we are on the topic of sliders / spinbuttons / entry widgets, I'd like to > point out that it would be nice if the same discussion could be applied to the > l&c&p dialog where transparency in the layer is concerned. I like the slider, > but it would be very nice to have the number next to it (the transparency > percent) be interactive via a text entry blank thing. > > It would be a Good Thing [tm], imo. Agreed. Maybe a spinbuttons, since you can adjust that more powerfully with the keyboard (shift-up for +10, up for +1 etc..) > PS: I like having a slider better than a spinbutton on the ink tool because you > can slide it all the way to the max or min w/o having to incriment slowly > one-by-one (like with a spinner) Good point. I agree too. What about adding a "Tilt this to max/min" -togglebutton next to the slider and spinbutton so you can toggle the 0/max values really fast (no, this is just a joke that perhaps might wake you up. We really wouldnt want do do this :) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: limited slider range
On Thu, Oct 28, 1999 at 12:38:34AM +0100, Guillermo S. Romero / Familia Romero wrote: > >I know I'm repeating myself, but why not use _both_? In the case of > >the opacity slider, the number is displayed right beside it. Making > >this number a spinbutton would not take up very much more screen real > >estate and it would allow everyone to work with the value in the > >manner they prefer. > > And will make 50% a real 50% and not vary with the size of the slider making > it 49.7 most of times (just an example, maybe typical is 49.9). Though in gimp tool options it is usually much more about adjusting a value based on the visual appearance of the image (like layer opacity) and not a precise value.. Certain sliders could go even without a label and you could still use them just fine.. > >I'd like to see more slider/spinbox combinations in the GIMP. The > >slider is great for figuring out the correct value but being able > >to tune it by typing in a number is essential for precision work. > > Maybe right click slider to launch a dialog where you input precise numbers? > by keyboard It also could show max and min values, or recommended values. > The number is there in most of the sliders, so I see no serious problem > about space: click number, dialog appears. Or convert number to input area. Not a dialog IMHO, the dialog is always an evil extra step. Rather the convert-the-value-to-input - though it should just be an input already.. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
