Difference between revisions of "SetColorSignal"

From Inkscape Wiki
Jump to navigation Jump to search
 
m (Reverted edits by VmhHsm (Talk); changed back to last version by Colin Marquardt)
 
(8 intermediate revisions by 4 users not shown)
Line 7: Line 7:
The signal carries at least one parameter which specifies whether this color is to be applied to the stroke or to the fill. Some callbacks use it, some ignore it (see below).
The signal carries at least one parameter which specifies whether this color is to be applied to the stroke or to the fill. Some callbacks use it, some ignore it (see below).


Ideally, the signal may also carry a more complex ColorChange struct as a parameter, which would indicate which channels in which color spaces are to be changed by what values. This will allow us to set e.g. transparency of the fill of selected objects without changing the fill color, or vary the HSV saturation of the current stroke color without changing the hue. (See [http://sourceforge.net/tracker/index.php?func=detail&aid=937393&group_id=93438&atid=604306 |bug 937393])
Ideally, the signal may also carry a more complex [[ColorChange]] struct as a parameter, which would indicate which channels in which color spaces are to be changed by what values. This will allow us to set e.g. transparency of the fill of selected objects without changing the fill color, or vary the HSV saturation of the current stroke color without changing the hue. (See [http://sourceforge.net/tracker/index.php?func=detail&aid=937393&group_id=93438&atid=604306 |bug 937393])


== Sent by ==
== Sent by ==
Line 23: Line 23:
* SPDesktop itself, before emitting the signal, sets its internal current_color fields (fill and stroke stored separately, in RGBA). Then the signal is sent.
* SPDesktop itself, before emitting the signal, sets its internal current_color fields (fill and stroke stored separately, in RGBA). Then the signal is sent.


* CurrentColorWidget: catches signal, udpates its color display (fill and stroke stored separately), returns FALSE
* [[CurrentColorWidget]]: catches signal, udpates its color display (fill and stroke stored separately), returns FALSE


* Fill and Stroke dialog: catches signal, updates its active color picker on the corresponding tab, returns FALSE
* Fill and Stroke dialog: catches signal, updates its active color picker on the corresponding tab, returns FALSE
Line 29: Line 29:
* Text selection: in text context, if there is an inline selection, it catches the signal, creates tspan (if not yet created) and applies the color to it (fill and stroke separately). This way you can select a word in a line by shift-arrows and paint it red by clicking on the palette. Returns TRUE to terminate signal processing.
* Text selection: in text context, if there is an inline selection, it catches the signal, creates tspan (if not yet created) and applies the color to it (fill and stroke separately). This way you can select a word in a line by shift-arrows and paint it red by clicking on the palette. Returns TRUE to terminate signal processing.


* Gradient node: with on-canvas editing of gradients, each stop is represented a node, and one of the nodes can be selected. In that case it catshes the signal (disregarding the fill/stroke parameter) and applies it to the selected node. (TODO: A gradient must never be shared between objects unless they are clones, or unless it is requested specifically; applying a gradient to an object creates a copy of the gradient, as does duplication of the object.) Returns TRUE.
* Gradient node: with on-canvas editing of gradients, each stop is represented a node, and one of the nodes can be selected. In that case it catshes the signal (disregarding the fill/stroke parameter) and applies it to the selected node. The same applies to the gradient editor dialog: when open and when one of the stops is selected, signal sets that stop's color. (TODO: A gradient must never be shared between objects unless they are clones, or unless it is requested specifically; applying a gradient to an object creates a copy of the gradient, as does duplication of the object.) Returns TRUE.


* When all callbacks are finished, if the returned value is FALSE (i.e signal was not consumed by text selection or gradient node), SPDesktop applies the colors to the objects in the current selection (fill and stroke separately).
* When all callbacks are finished, if the returned value is FALSE (i.e signal was not consumed by text selection or gradient node), SPDesktop applies the colors to the objects in the current selection (fill and stroke separately).
[[Category:Developer Discussion]]

Latest revision as of 15:48, 20 April 2007

The proposal:

The set_color signal is a signal that is emitted on an SPDesktop object by various color-selecting widgets and commands and is processed by the various selections and color-displaying widgets.

Parameters

The signal carries at least one parameter which specifies whether this color is to be applied to the stroke or to the fill. Some callbacks use it, some ignore it (see below).

Ideally, the signal may also carry a more complex ColorChange struct as a parameter, which would indicate which channels in which color spaces are to be changed by what values. This will allow us to set e.g. transparency of the fill of selected objects without changing the fill color, or vary the HSV saturation of the current stroke color without changing the hue. (See |bug 937393)

Sent by

  • The dropper tool sends this signal when picking the current fill color from the canvas. By default it sends the fill signal, with shift+click it sets stroke.
  • The palette widget: fill color on click, stroke color on shift+click.
  • The fill&stroke dialog: when flat color tab is active, it sends fill or stroke set_color depending on which tab (fill or stroke) is active. Gradient tab do not issue this signal (and will be eventually removed anyway, once we have on-canvas editing).

Received by

When SPDesktop's function to emit the signal is called, the order of events is as follows:

  • SPDesktop itself, before emitting the signal, sets its internal current_color fields (fill and stroke stored separately, in RGBA). Then the signal is sent.
  • CurrentColorWidget: catches signal, udpates its color display (fill and stroke stored separately), returns FALSE
  • Fill and Stroke dialog: catches signal, updates its active color picker on the corresponding tab, returns FALSE
  • Text selection: in text context, if there is an inline selection, it catches the signal, creates tspan (if not yet created) and applies the color to it (fill and stroke separately). This way you can select a word in a line by shift-arrows and paint it red by clicking on the palette. Returns TRUE to terminate signal processing.
  • Gradient node: with on-canvas editing of gradients, each stop is represented a node, and one of the nodes can be selected. In that case it catshes the signal (disregarding the fill/stroke parameter) and applies it to the selected node. The same applies to the gradient editor dialog: when open and when one of the stops is selected, signal sets that stop's color. (TODO: A gradient must never be shared between objects unless they are clones, or unless it is requested specifically; applying a gradient to an object creates a copy of the gradient, as does duplication of the object.) Returns TRUE.
  • When all callbacks are finished, if the returned value is FALSE (i.e signal was not consumed by text selection or gradient node), SPDesktop applies the colors to the objects in the current selection (fill and stroke separately).