[Recolor] GSoc 2013: Week 2 Brickwall
Hello, As a follow-up to my first week, I have been digging into numerous source files to get a hold to the functionality that handles coloring objects selected on the canvas ( desktop ) .
The file paint-selector.cpp is a generic file which handles the different color selectors like the color-wheel selector( sp-color-wheel-selector.cpp ) which is our attention right now.
Now, the FillNStroke class (fill-style.cpp) puts the Paint Selector in the appropriate mode.
The Paint Selector then passes control to the color selector which repaints the object on the canvas which is selected. There is just one problem with respect to the demands of my project : The color selector will apply changes to ALL objects currently in the SELECTION list. What I need is that a group of objects are selected, with the ONLY ONE object selected or atleast the color selector thinks so ?
Any ideas on how I actually create such pseudo-selection criteria ?
I have an approach in mind that goes like this: I can include an extra Paint Selector mode by the name of MODE_RECOLOR and in that mode the desktop handles the selection differently that it maintains a list of background selections and an ACTIVE selection. The ACTIVE selection is what the color selector sees. When I toggle the selection, the appropriate object becomes the ACTIVE SELECTION. There must be many experienced developers here who know the in and outs of the coloring mechanism. Can you guys suggest a better solution/ go-ahead whether my proposed way is possible/ an easier method ?
Waiting eagerly for a reply.
On Thu, 2013-07-04 at 19:09 +0530, Arshdeep Singh wrote:
Any ideas on how I actually create such pseudo-selection criteria ?
This sounds like a design problem. Can you explain how the user would interact with the user interface to set the colour profiles?
In general I would be wary of having multiple selection modes/contexts for the object level. There are tools such as the align tools and text on path tools that do special things with the selected items, the first or last selected or only work if the right kinds or numbers of items are selected.
Martin,
Hi Martin,
Thankyou for your reply. This was precisely I wanted to discuss the case with experienced developers.
The recolor tool is intended to enable more than one solid color editing for selected objects on canvas. A few events that will occur : 1.) When objects are selected on the canvas, the wheel will be 'refreshed' and will show a number of white draggable nodes on the wheel according to the color of the objects on canvas they pertain to. ( adobe.kuler.com ) 2.) When I select a node on the wheel, I should be able to actively edit its color. Switching to a new node, should shift the focus to that objects.
I studied the code, and the paint-selector class handles just one active selection. If we don't find a work around, we will have to change the inner workings of the coloring mechanism for our needs.
To set the color, the user will drag the node on the wheel and change the saturation and/or hue. There is a bar at the bottom added to handle the Brightness Value. So on changing the node on the wheel should refresh the brightness bar for the color the object has right now. Here's a screenshot:
[image: Inline image 3]
On Thu, Jul 4, 2013 at 9:58 PM, Martin Owens <doctormo@...400...> wrote:
On Thu, 2013-07-04 at 19:09 +0530, Arshdeep Singh wrote:
Any ideas on how I actually create such pseudo-selection criteria ?
This sounds like a design problem. Can you explain how the user would interact with the user interface to set the colour profiles?
In general I would be wary of having multiple selection modes/contexts for the object level. There are tools such as the align tools and text on path tools that do special things with the selected items, the first or last selected or only work if the right kinds or numbers of items are selected.
Martin,
2013/7/5 Arshdeep Singh <moduli16@...400...>
Hi Martin,
Thankyou for your reply. This was precisely I wanted to discuss the case with experienced developers.
The recolor tool is intended to enable more than one solid color editing for selected objects on canvas. A few events that will occur : 1.) When objects are selected on the canvas, the wheel will be 'refreshed' and will show a number of white draggable nodes on the wheel according to the color of the objects on canvas they pertain to. ( adobe.kuler.com ) 2.) When I select a node on the wheel, I should be able to actively edit its color. Switching to a new node, should shift the focus to that objects.
I studied the code, and the paint-selector class handles just one active selection. If we don't find a work around, we will have to change the inner workings of the coloring mechanism for our needs.
The 'coloring mechanism', e.g. the paint selector in the bottom left corner and the underlying code, is not designed to work with multiple objects, and should not be. As I understand, MODE_RECOLOR would be an awful hack and trying to push a square peg through a round hole. You need to work with the Inkscape::Selection object directly. You can access this object through SPDesktop. If you need some helper functions from the paint selector, refactor them so that they're not bound to the paint selector object.
To update the dialog when the color of objects in the selection changes, you can use XML observers. (Admittedly, the lack of any notification mechanism on the SP tree level is a major design shortcoming.)
Regards, Krzysztof
Ah I see, he was using a special interface and not the Inkscape::Selection. That explains the problem.
Off topic somewhat:
Tell me, does inkscape have a way to turn used colours into a pallet? I just tested the 'auto' pallet and it didn't do anything. So I'm not sure what 'auto' does, nor if the idea of a used-colour pallet has been implemented yet.
Martin,
On Fri, 2013-07-05 at 19:33 +0200, Krzysztof Kosiński wrote:
The 'coloring mechanism', e.g. the paint selector in the bottom left corner and the underlying code, is not designed to work with multiple objects, and should not be. As I understand, MODE_RECOLOR would be an awful hack and trying to push a square peg through a round hole. You need to work with the Inkscape::Selection object directly. You can access this object through SPDesktop. If you need some helper functions from the paint selector, refactor them so that they're not bound to the paint selector object.
To update the dialog when the color of objects in the selection changes, you can use XML observers. (Admittedly, the lack of any notification mechanism on the SP tree level is a major design shortcoming.)
On Jul 5, 2013, at 2:42 PM, Martin Owens wrote:
Ah I see, he was using a special interface and not the Inkscape::Selection. That explains the problem.
Off topic somewhat:
Tell me, does inkscape have a way to turn used colours into a pallet? I just tested the 'auto' pallet and it didn't do anything. So I'm not sure what 'auto' does, nor if the idea of a used-colour pallet has been implemented yet.
It more is the representation of 'solid colors' in the current document. It automatically adjusts to what is in whichever is the current document.
We can take it a bit more, but probably should keep workflows in mind. There are a few different ways to represent things, and even some internal cleanup that can be done to make things go easier.
Of course "solid color" and "colors in the current document" are very different concepts and can end up needing complex overlapped workflows.
On Fri, 2013-07-05 at 20:37 -0700, Jon Cruz wrote:
It more is the representation of 'solid colors' in the current document. It automatically adjusts to what is in whichever is the current document.
OK, so it should do something, but it's currently broken in trunk? I just set a bunch of shapes to have a bunch of colours and Auto continues to be empty.
Martin,
On Jul 5, 2013, at 9:51 PM, Martin Owens wrote:
On Fri, 2013-07-05 at 20:37 -0700, Jon Cruz wrote:
It more is the representation of 'solid colors' in the current document. It automatically adjusts to what is in whichever is the current document.
OK, so it should do something, but it's currently broken in trunk? I just set a bunch of shapes to have a bunch of colours and Auto continues to be empty.
Last time I checked it was working in trunk, but just might be doing something other than what you expect.
Some of the convenience menu items appear to have been removed and/or changed as a "cleanup" or such, but key functionality should still be there.
To check functionality, have the "auto" palette selected, go into the Fill&Stroke dialog, then change some object's fill color from "Flat color" to "swatch" instead.
In the palette, you should see a new color show up. Try dragging this color onto several other objects.
Now, click on something other than the color-assigned objects. Click back. Repeat. Whenever you do this you should see a "selected" marker show up on the solid color that is in your current selection (if any). Since that is a single referenced "solid color" it is easy to track its use.
Now for the main magic trick. After you have several objects using a given color in the auto palette, right click on the palette entry and "edit" it. You might need to enable the legacy gradient editor for this phase. *If* things work you should get the edit UI for the swatch. If not, then you can edit it from the defs. Once you do change the color you should see all objects that had the color assigned change all at the same time.
On Fri, 2013-07-05 at 22:25 -0700, Jon Cruz wrote:
In the palette, you should see a new color show up. Try dragging this color onto several other objects.
Now, click on something other than the color-assigned objects. Click back. Repeat. Whenever you do this you should see a "selected" marker show up on the solid color that is in your current selection (if any). Since that is a single referenced "solid color" it is easy to track its use.
Now for the main magic trick. After you have several objects using a given color in the auto palette, right click on the palette entry and "edit" it. You might need to enable the legacy gradient editor for this phase. *If* things work you should get the edit UI for the swatch. If not, then you can edit it from the defs. Once you do change the color you should see all objects that had the color assigned change all at the same time.
It works as explained. A simple change would be to rename 'Auto' to 'Swatches' and leave an auto feature for the future perhaps.
I'm a bit concerned about the design/workflow, it's convoluted for just colour tracking and with all that gradient business, it must be trying to do something advanced that I can't divine atm. Do we still have any blueprint/designs kicking around that explain some of it?
Martin,
participants (4)
-
Arshdeep Singh -
Jon Cruz -
Krzysztof Kosiński -
Martin Owens