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 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
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
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/ | `---'
