The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: some thoughts
by me on Wednesday 06/Sep/2006, @05:23
|
These widgets are *very* nicely usable. To be honest, I think opensource lacks a little in the widget-department. For example, there are STILL input fields for INTs from 0 to 100 that have up-and-down-arrows. How useless is that?
It would make sense if one could hold the field and then move the mouose to adjust the value, but who actually taps these two buttons?
Honestly, there's a lot of stuff, especially annoying in krita, karbon14 etc.
I know this sounds harsh, and we all know that I won't commit any coolSliderThingy.{h,cpp} to svn myself, but please, try these widgets first! You'll see, training is not needed!
|
[
Reply To This | View ]
|
Re: some thoughts
by BenAtPlay on Wednesday 06/Sep/2006, @07:40
|
The Adobe widget looks like a subclassed QLabel with the mouseMove/mousePress/mouseRelease events overriden. It shouldn't be too hard to override. The difficult part would be to get the context menu working right IMHO.
Cheers
Ben
|
[
Reply To This | View ]
|
|
Re: some thoughts
by ac on Wednesday 06/Sep/2006, @07:48
|
> And in the end the small buttons are not taking a lot of space at all so the advantages are pretty small to begin with.
It's true that those small up and down buttons do not take up much space, but I think they are entirely useless. Something like a QSlider is much better suited to vary a quantity over a fixed range. It seems to me that this proposed widget is basically a slider without actually showing it. How about temporarily displaying the slider when it's in "drag mode"?
By the way, what is this context menu good for? If I understand you correctly, you can already enter a specific value by simply clicking on the widget,
|
[
Reply To This | View ]
|
Re: some thoughts
by Gabriel Gazzán on Wednesday 06/Sep/2006, @09:31
|
- The "Edit Values..." option in the context menu mainly allows the user to redefine the span of the slider (its Mínimum and Maximum values). This is sometimes useful in certain cases where the default span is so big that you lose precision while dragging (perhaps changing from 1 to 2 is already a great change in the effect, but as the slider goes from -1000 to + 1000, each time you drag the value changes too much and the slider turns "incontrolable", so lowering the span of the slider increases this precision while dragging and makes it comfortable again).
In theory the span should be preset by the programmer to "useful" values, but often users use effects in situations not foreseen by the programmer, so I guess is in these cases when this option is more appreciated.
- The other useful option in the context menu, is one allowing to "Reset" the value to their default state. Good after you've been experimenting and want to return safe home. :)
p.s. I completely agree on the current state of sliders in Qt/KDE, I never use them, to me they are useless and I end entering values by hand, which is very disrupting, workflow wise.
"Lightwave 3D" and "3ds max" are good examples of programs with good and useful sliders, but to be honest since Adobe introduced this kind of "nano" slider I prefer it over everything else, as they've had a very strong impact in how the (same) applications feel by improving the workflow tremendously.
|
[
Reply To This | View ]
|
Re: some thoughts
by Gabriel Gazzán on Wednesday 06/Sep/2006, @16:36
|
> p.s. I completely agree on the current state of sliders in Qt/KDE
I really meant the up and down buttons to the right of numeric input boxes, not the sliders.
My confusion came from the fact that in some programs (e.g. Autodesk 3ds Max) this buttons function as sliders when dragging up and down over them, so I tend to see them as sliders too.
|
[
Reply To This | View ]
|
Re: some thoughts
by Gabriel Gazzán on Wednesday 06/Sep/2006, @10:25
|
I thing that the beauty of this kind of "hidden slider" is that the precision is not restricted to the small screen space where the slider resides.
Let me explain myself:
If you put a visual slider widget on the screen you have to make it "small" (I still haven't seen widgets with a screen wide extension) :)
But this small extension constraints you to put all the possible values the slider could take, from one extreme to the other, so I could end with a 3cm long widget for changing values from -500 to +500, or -2000 to +2000, so this will make the slider behave with a very low precision, mining its usefulness.
With this "hiden slider" paradigm the extension is also "virtual", so in theory it could be made as long as necessary to make the slider progress in a much more soft way, making it more useful.
Besides that, if the user wants to enter a value directly, he still can.
The other thing I would like to refute, is that this kind of solution is not intuitive.
In this Internet era, if there is something users (even novice ones) know, is that if there is a colored underlined word in the middle of the screen, they could click on it to make something happen.
In this case, what needs to be made clear to the user is that they can not only press on it, but to also drag on it from side to side, and I think that this is the main reason for Adobe chosing to show a cursor with an index pointing hand with left and right arrows when over the "hidden slider".
Finally, I teach Adobe and 3D animation programs since more than 5 years ago, and let me say this is one of the features people love at first sight in the new versions of Adobe programs, perhaps followed by the new dockable option palettes (something Krita already has! kudos!)
I really think this is the way to go, not only for Qt/KDE, but in general for interfaces.
But of course it's just my opinion.
Cheers
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
