Looking for some feedback on addressing issue #122.
Here’s what I propose:
Implement this in 2 stages. Stage 1 can be done relatively quick. Stage 2 would require an update of all the tool dialogs, plus the addition of the “Current Pen” toolbar.
First Stage:
Add a View menu toggle item View->Point label
submenu toggle item Point label->Show all (Shift + L)
submenu item Point label->Increase size (Shift + +)
submenu item Point label->Decrease size (Shift + -)
Add a Point Label Toolbar duplicating Point label actions
Add a default Point label color preference in the App preferences.
Add a right mouse button context menu toggle show / hide individual point labels
Second Phase:
Integrate the color and size of a tool’s Point label with the Groups and the Point Label Toolbar.
There are several different ways to implement the color and font size, and this is where I could use some feedback. First let me explain somewhat how a Current Pen and Groups would handle colors for the tools:
First you thing you would be able to do is set a “Default” pen color in the prefs (and lineweight & linetype - but that’s neither here nor there for this discussion). When the app starts a “Current Pen” Toolbar is created using the default pen. The current pen can then be changed in the toolbar. Whenever a new tool is created the dialog will use the values of the Current Pen… so you don’t have to keep changing the Black - Solidline to say Pink - Dashed. What a concept. At any time you can “Reset” to the default set in the prefs.
Now… for a paradigm shift is the idea of having a Group Manager, where you can create groups before adding objects to them. Part of creating a group is setting it’s color (and lineweight & linetype).
And this is where the shift really happens - as you create a new tool, you can select WHICH group to add it to, and choose whether to use the “By Group” color (and lineweight &b linetype). You can then at any point edit an object’s properties to remove the object from a group OR even move it to another group.
Ok… that should give a good idea how the groups would function… where they can really be used more as a style. For example you could create a Group Seamlines, using a Black Solid line, and a Group Internal Paths using a Pink Dashed line.
So the question is how to integrate the label color (and size) into the groups.
The simplest thing to do is set all the labels color (and size) to a default pref setting?
A bit harder thing to do is set a tool’s label to match the tool’s line color (and a default pref for the size)?
The hardest thing to do, but would allow the most user freedom is to allow each tool point’s label to have it’s own color (and size), separate from the tool line color. This would require additional comboboxes in the dialogs as well as additional attributes in the XML schema. In this case we could also implement a “Current Label” color (and size) in the Point Label Toolbar similar to the Current Pen Toolbar, where a new tool uses the current label values, which of course you could override. Also the question is - do we just allow the use of a group’s line color for the labels, or do we add an additional group label color - where the point label color -> ByGroup would use that value, while the tool’s line color would use the group’s line color?
Right off the top I’m wondering about a set of saved Pen Attributes, accessible either via the menu, or a key combo such as P-1, P-2,… P-0.
I’m not very clear on how Pen Attributes & Layer Attributes are supposed to intersect though. It might make more sense to just place entities in different Layers
Other than that, I think that I agree with what Grace said. Though I imagine that it might eventually prove desirable to control point-label color separately from point/line color. However, unless putting it off would make it way harder to implement, I think it’s best to assume that we’ll be better off without it.
Do you mean “as you create a new object (point, line, curve, etc.) you can select WHICH group to add it to” ? So a dropdown box to select from existing groups? This would add a lot of value to the patternmaking workflow, and the beneficiaries would be the majority of Seamly users.
Defaulting an object & it’s label to the color of the tool that created it will add tremendous value for the patternmaking workflow, and the beneficiaries would be the majority of Seamly users.
Overriding an object’s default color with a color selected by the user doesn’t add universal semantic value, but it could be helpful to some users. The beneficiaries of this wouldn’t be the majority of users, even though any user could use it and appreciate it. This would be “Nice to have”. You stated this is the hardest, so the level of effort needed to implement this feature doesn’t match the benefits.
Big effort + low value + low beneficiary group = not a good product development choice. We can keep the feature request on the books in case this situation changes in the future.
So… We should choose door #2 to keep the product useful and moving forward, without adding bells and whistles that would be ‘nice’. Maintenance is a concern as well. When we share patterns, the default color schema will be stored in the top area of the file. But someone who inherits or purchases a pattern, how will a color override be conveyed? This breaks the semantic meaning of the colorscheme we’re trying to implement. I’m not comfortable implementing a way to break a system at the same time that we’re trying to create it. So please don’t do option #3, even though it sounds harmless, I think it breaks this semantic color feature rather than support it.
It would be a little more work to add a separate label color for tools, but since the class members and schema would need changes anyway, not that big a deal.
Yes. You would be able to either use the Group manger to create new group(s) or create a group in the existing manner… and then when you create a new tool there would be a combobox in the tool dialog to select which group to put an item in - the default being none. Editing the tool options you could also change the group (none would remove the tool) in the combobox.
Hardest was probably not the best choice of words… it’s not “hard” to add a new tool attribute “labelColor”. I have to add a new attribute “showLabel = false/true” anyways so coding another label attribute is not a big deal.
There is no “default” color schema… it’s hardcoded as black.
If it’s a previuos schema it would be black… if colored label schema it would be what ever the user used to create the pattern. No different than what line color they chose.
I don’t get your point? There’s no breaking a system… as there is no system Again… it would be no different than saving a lineColor attribute in the pattern file… which if it is empty the lineColor defaults to the hardcoded Blaok. If there was no labelColor it would default to Black.
That being said… option #2 would basically use the lineColor attribute for the label color - which could be “byGroup” as a choice. The only minor issue then is the attribute name becomes a little misleading as not only is the color the line color it’s the label color and as such the attribute name should just be “color”.
No. I’m saying that’s how it is now. That’s NOT good as you can’t change the color of the label… which is part of the issue description. My options were:
Use a singe default color set in the prefs.
Use the tool’s lineColor,
Use a (new) separate “labelColor” for each tool’s label.
Where options #2 and #3 could use a group defined color - “byColor” in a drop down combobox.
It’s should not be up to the app to decide what color something should be… it should be the users choice to configure it as they want. If there was a universal industry standard that would be a different story. Just for ex… what if a user is color blind? How would your color scheme work for them? It probably wouldn’t
One possible idea is to create a set of group “presets” that are hard coded, and allow for user defined groups stored with the pattern. For example there could be a list of groups:
Cut lines - Black - Solidline
Internal - Blue- Dashed
Construction lines - Pink - Dotted
etc…
user defined
When you create a tool you simply select the group to put it in.
That being said… right now we’re only talking about the display in draft mode - using colors in the actual pattern pieces is another whole story. There is a very good reason for ex: to have cut lines, symbols, internals, etc in different colors when it comes to using machine cutters. Or there is good reason to color pattern pieces according to material or size.
Ok, tell me where I’m wrong as I visualize how this is used:
Tool colors: Users can define colors for tools that create the point, line, curve, arc, and elarc objects. These colors are displayed in Draft mode on the objects in the gui. These tool colors aren’t saved to the pattern.
Group colors: Users assign colors to groups. The group colors affect the labels in Draft mode. The group colors are saved within group information in the pattern.
One of the things I’m working on is how to support remote teams to develop patterns, so was wondering how color info could be shared so the pattern can be discussed. Shared color info might make the discussion easier, just as it makes the work of an individual user easier.
Yes they are! It’s the attribute “lineColor”… as well as “lineTyoe”. Where do you think they are saved?
Yes. The user creates a group, and defines a color for it. Then as in the picture above, the user can select what group a tool is in, and IF it’s in a group the linecolor option “By Group” is available in the combobox. The Group color attribute is saved in the “group” tag. if we choose to we could add an additional tool attribute “labelColor” (Option #3) so the color for individual labels can be set.
How about this… we have the option in the Groups Manager to load / save group presets. A preset being a list of groups with the various attributes. There could be a “default” preset that comes with the app. The user could choose to load the default preset, or create their own set of groups and save the preset - which could also be shared. When the pattern is saved it would save the groups as normal. If you want a team of users to develop patterns they could simply use the default preset ??
So, (speaking as a time-traveller,) normally the user’s color/attribute presets are just stored in the Preferences/.config file, but there is an option to export them to a text file, (probably defaulting to Layouts, because that’s where all the weird stuff defaults to,) & there’s also an option to import from file, so that people using different workstations can use the same color/attribute presets without having to manually enter every variation from black.
& we are currently speaking of attributes as applied to draft blocks, which is separate from the eventual ability to apply colors to pattern pieces, (which will possibly occur in a different app of the Seamly suite.)
However, the attributes applied to the draft are saved in the VAL, which is also referred to as the pattern, but refers more to the draft block than to the pattern piece.
Agreed. That’s why I suggested the user being able to store color presets, or more specifically a “style” preset that would define the line type, lineWidth, color. And yes normally we would store the prefs in the Seamly2D.ini (SeamlyMe.ini) file… but to share we would either have to be able to export / import presets, or just move the the style settings out of the ini file to preset files - where there is a default preset provided - and the user preset is stored in the prefs. Then we just provide load / save options in the ui for the presets - that could easily be shared with others.
Yes. Any “style” attributes for pattern pieces could apply to either identifying a size or a material choice. Color coding is a wonderful thing! Plus the pattern piece style attributes can have significance outside the app when it comes to printing, plotting, or cutting.
Yes. Currently all the tool line style attributes are stored in the pattern file (.val).
Just a note… I have the app working to implement the options to hide / show all Point Name (labels) and set the font size larger / smaller from the View menu / key shortcuts, as well as showing / hiding a single point name via the context menu.
Currently the same settings apply in both the draft and view mode. Does anyone see any benefit to separate the 2 modes so they each have their own settings? Or is that just overkill?
Also I think I’m going to implement setting the Point Name label to the same color as the tool. ?? That would pretty address the parameters of issue #122. I can then address the tool “style” attributes as a separate issue which is really another paradigm shift in the way the app operates.
Here’s something I thought of… It makes sense to make the point name text* the same color as the tool line color while in draft mode - it doesn’t make sense when in piece mode as the tools don’t apply there.
I’m guessing we should leave them black in piece mode for now?
*I would rather use the term text vs label so as to avoid confusion with the pattern piece labels and all the ui form labels. Besides, the point name objects are QGraphicTextItems in the scene(s) so it makes sense to call them text.
@Douglas, you’re right…semantic colors don’t make sense in Piece mode, only in Draft mode.
And you’re right that text annotations should be called ‘text’.
‘Label’ should keep its current specific meaning, eg the Pattern label and the Piece label.
