improved options on the fill and stroke menus for easier customization

Registered by Robert

Currently the options within the fill and stroke menus are somewhat

limited compared to what they could allow. For example, when you select

"markers" on the "stroke style" menu, you have 3 options for where to

place markers, and a long drop-down list of markers without descriptions

and tiny and often nearly indistinguishable icons representing what they

should look like. The dropdown menus could be replaced with larger pop-

out menus or separate, larger sections of icons for each marker position

(beginning marker, node markers, and end marker.) A resizable and

organizable grid arrangement would be preferable to a dropdown menu as it

would allow the possibility to view and select from more of the available

shapes in greater detail without needing to scroll as often.

Furthermore, the current solution is made even more confusing by the fact

that there appear to be 3 sizes of the same marker for every style of

marker. This could be corrected by removing the duplicate sizes of

markers and simply adding X and Y scale options to the markers, giving

even more control over to the user. Currently when the user selects a

marker from the dropdown menu, the selected marker is added to a list of

recently used markers at the top of the list. This can be very

frustrating as when the same marker is selected multiple times, it is

added multiple times to the top of the list. The only thing indicating

the separate section devoted to the recently used markers is a thin grey

line. If a popout or separate section were implemented for markers, a

tab could be added for recently used markers as well as favorites and

other user-created categories, perhaps even separate tabs for user-

installed packs of shapes. My final suggestion for the markers would be

to add a new type of marker, the midpoint marker, which would measure the

estimated distance from the first node to each subsequent node all the

way to the end, adding the total distance together, then find the

estimated midpoint along the stroke and place a marker there. This

currently could be done with much effort from the user using the "mid

markers" by only using a single node other than the beginning or end

node, however the user would have to do the measuring by hand with much

effort. Creating more complex curves such as those that require several

nodes would be even more difficult. With the same basic infrastructure

the measuring of the center would provide, other features could be

implemented as well, for example markers every N units from the

beginning, or M number of markers evenly spaced along the curve. My

suggestion for changing the way the fill menu works applies only to the

"pattern fill" selection within the menu. Patterns should be selectable

similar to the way I have suggested for markers, with swatches arranged

in a grid. When a pattern is selected, options specific to that pattern

should appear below the currently selected swatch. For example, stripes

could have an aspect ratio between stripes, a number of stripes within

the pattern (for example the minimum would be 2 colors), a color selector

for each stripe, a rotation attribute for the whole pattern, so that the

pattern may be arranged independent of the arrangement of the shape it is

applied to, and an X and Y offset also for arranging the pattern

independent of the location of the object. Think of this as overlaying

an infinite stencil over a finite stencil. The infinite stencil is the

pattern, the finite stencil is the shape. It is useful to be able to

move either stencil independently or to lock the current location and

rotation in relation to the other. The current wave patterns could be

considered another type of stripe pattern. For patterns that arrange a

certain shape regularly, many other options could be added. For example,

independent rotation for each shape, the ability to select multiple

shapes on the same arrangement pattern, randomization or parametrization

of rotation, offset, scale, and color, etc. The more options made

available with the least confusion, the better. Advanced options could

be hidden by default in a collapsed "advanced options" section if things

get out of hand for beginner's usability. My final suggestion would be

to add context menu options when you right click on any shape, group of

shapes, or selection. The added context menu options would be to define

path as stripe pattern, define shape as pattern, or define marker.

Stripe pattern paths would apply to the stripe and wave type of patterns.

 The user could define any shape having a separate beginning and endpoint

as a pattern to be looped repeatedly along as stripes. The other two

context menu entries should be fairly self-explanatory. Infinitely

repeating seamless patterns could be defined using the same context

selection as normal shape patterns by selecting the proper spacing to

align the edges after definine a pattern shape.

Semi-unrelated ideas:

Patterns and shapes as opacity masks?

Multiple opacity masks for varying levels of opacity?

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Robert
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

[2015-02-03 ~suv] Please consider reformatting your blueprint text. Alternatively, you could create a proposal page in the wiki as blueprint specification - there you can use wiki formatting to structure the text - and link it as URL for the spec, while keeping just a concise summary here on the blueprint page.

I gave up rather quickly reading this wall of unstructured text - before I was even able to get at least a basic idea what this blueprint might be about.

[2015-02-07 ~rburge1988] Noted and I will work on restructuring it, however I did as instructed by the "Summary" section's subtext which reads "A single-paragraph description of the feature. This will also be displayed in most feature listings." I wasn't happy about the giant wall of text either which is why I copied it into another text application and at least double-spaced it before submitting it. However I didn't want to break the aforementioned one-paragraph rule. Perhaps what is written underneath the Summary's entry box should be amended to clarify that we should place more long-winded descriptions on a wiki page. As a newbie here I had no idea that this was the standard protocol. Thank you for at least clicking and giving it a glance. I apologize for any migraines I may have induced.
Update: I've just requested access to the wiki through the mailing list. Hope to be able to upgrade this textual abomination soon. Again, very sorry for any migraines. I suffer them myself and text walls trigger my own.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.