Advice on widget styling for custom widget

[rivimey]

Hi, I am currently writing a new widget (group) to implement a gradient editor* tool similar functionally to that implemented by the Gimp**. I have at present implemented a gradient object which can manage and deliver QColors on demand, and a widget that uses this to fill its area in those colours. I found the code for the "range" slider in Qxt (QxtSpanSlider) and am currently assuming I will generalise this to the multi-segment operation I want. [advice on other options here??]

My question is graphical, really. The slider handles I want are arrows to points on a line rather than virtual "grab handles" and while those provided in QPlastiqueStyle (a square with an arrow on top) aren't bad, other styles aren't so good. Would it be better to implement what I think is good and ignore the application styling, or make do with what is available?

My thought at the moment would be a square with a triangle on top for the handle, and a straight line running away from the peak of the triangle.

Thanks for your help,
Ruth


* Gradients here consist of multiple segments each of which is x-mark-y (x,y are fixed colour endpoints, mark is an adjustment position), so you might have a gradient that went blue-green-red-yellow-black... for example.

** http://gimp.open-source-solution.org...-gradient-edit

[wysota]

Implement what you think is good.

[d_stranz]

Even though you have already implemented your gradient object, you might want to take a look at the colormaps as provided in Qwt. They are essentially a gradient of the form you describe (0 - mark - ... - mark - 1) where each mark is a color stop with 0 <= value <= 1. The colormaps map a real-valued range onto the (0 - 1) range defined by the map and return a QColor corresponding to a real value in the range. I implemented a gradient editor in my app using this; see below. In this case, except for the color selection buttons, all of the widgets are stock so there is no problem conforming to application style. Even the color buttons are just QPushButton instances with an icon with some built-in coding to post a QColorDialog when clicked, so they are painted in the correct style as well.

PlotWizardGradient2.jpg

I personally think the example you show from GIMP is ugly and is probably difficult to use in practice. The triangles are too big, and it seems it would be too easy to click on the wrong one. As Wysota suggests, implement what is pleasing to you and fits with the rest of your UI style. I would use elements from the application style to paint other parts of your widget such as backgrounds, borders of sub-elements, etc. so that if the user chooses a different default style your widget UI will at least be in accord with most of it.

[rivimey]

wysota, d_stranz, thanks for your comments and that screenshot. I agree that the GIMP editor is horrible to use, but I would like to retain one feature of it - that the slider widgets relate directly to the colour bar.

I hadn't (until I was browsing last night) noticed the Qwt colourmap tool; it would have been useful a while ago, but I've now implemented the GIMP form of gradients, which is a bit more complex in that each segment has two end colours and a mark in the middle, which controls the rate of change from one end to the other, and you can select one of 4 maths functions as to how that is done.

I'll take the advice and see how it goes; I may well see if I can inherit a Push button for the slider handles; I want to be able to click them to change the colour anyway. Any suggestions for colour selection widgets?

As an aside, it does occur to me that the Qxt and Qwt groups would benefit from working together and possibly merging the libraries...

Regards
Ruth

[d_stranz]

Qxt and Qwt, aside from being adjacent in sort order, seem to be pretty orthogonal libraries to me. Qwt is pretty strongly focused on technical data graphics, while Qxt is a set of more general extensions to Qt.

For the purposes of my app, the two fixed endpoint colors and up to three stops proved sufficient. If I were to do it again, I would probably take the color gradient bar widget (above the sliders) and generalize this to hold markers for the stops, with a UI something like this:

• Two fixed (immovable) markers at 0 and 1, for the two endpoints, and movable markers in between (initially none).
• Clicking the gradient bar between two markers adds a new (movable) one at the position of the click. Color is initially set to the colormap value at that location.
• Clicking and dragging a movable marker changes its position. Once it bumps up against another marker, the other marker moves with it. (This same behavior is implemented in my sliders - once one slider reaches the value of another slider above or below it, the other slider moves in tandem). This makes it impossible to slide one marker past another.
• During sliding, the value of the stop is displayed above the marker, then is hidden once movement stops.
• Clicking (maybe double-clicking?) on the marker brings up a color selection dialog.
• Right-click brings up a menu, one option would be to delete the stop.
• Tooltip on hover over a marker to show the current RGB and stop value.

I would make the stop markers themselves very simple - essentially small colored squares on the end of a stick, like a lollypop. The stick extends across the gradient bar, the squares sit just above it.

The general idea is to make this a small, self-contained widget, occupying a minimum of real estate, unlike the current editor which requires an entire dialog page to accomplish the same thing.