improved options on the fill and stroke menus for easier customization
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
- Started by
- Completed by
Related branches
Related bugs
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.