I checked further and there’s 1/2 dozen tools that are over riding the Pen Toolbar lineType and lineWeight.
I’ll remove this from all these tools.
Which actually reminds me of 2 items:
I have to resolve the issue of adding the color / linetype / lineweight - ByGroup, where the attribute is set by the Group Pen attributes. I have the issue due to the desire to keep the behavior of being able to add a tool to more than one group. The problem is if a tool is in more than one group - which group pen attributes does the tool use if set to ByGroup?
I also want to add Pen style (a style consists of the color / linetype / lineweight) presets to the Pen Toolbar, where you can just load a style preset to set all the attributes based on the style you want. For example: Doug’s custom preset could be - Construction lines - cornflowerblue / dash / 0.05… Drawing lines - black / solid / 0.80…etc. Also we would have a semantic “Standard” style preset that’s built into the app. The “Standard” being something open for discussion of what line styles should be included - keeping in mind it would need a light and dark mode assuming at some point we address working with dark mode.
I think black is the general default when none is set differently… So, if a pen style isn’t specified and an object belongs to multiple groups, then shouldn’t it default to black to indicate this? Either that, or perhaps one can set a colour as the default “multiple groups” colour? Or to desplay the colour of the 1st group (in the list) that’s visible.
This sounds very fancy I love the idea that we will be able to set custom presets, but won’t these be over ridden by the group styles? Perhaps one should choose whether one wants the style presets or the group styles? Then one can approach the matter from there?
My thoughts (but don’t be cross if I’m missing the point)
I would regard a group as a special item where the original object is referred to by a pointer. The original (say it is black) may be pointed to a blue group. Where the original stays black and the grouped item may appear blue. It would be like the pointer adds or changes some attributes of the item in the mirror.
On the other hand there is the thought why would we need to change the color of an object the moment it is grouped?
I think as a standard being a white background and black anything else should suffice. Personally I seldom use the dark mode of software. It feels far more intuitive to draw with a black ‘pen’ on a white ‘sheet’. But I do know many people like dark skinned software.
Finally, giving the option of more then one item in the preset (construction vs drawing lines) would benefit in my view from a shortcut key combo to easily switch.
That’s how it would function… or at least that’s how I had it working on my 1st fork before I started working with Seamly. Really slick thing here is that you could assign a tool to a group AS you create the tool. If the tool was assigned a group you then had the opton to use the ByGroup pen attributes… otherwise the default color is used.
BUT… that’s not the problem. The problem arose because some users need to retain the ability to place a tool in multiple groups, there’s the issue WHICH group attributes are used? To me it makes no sense to put an object in multiple groups, just like you can place a file in multiple folders - it can’t be in 2 places at the same time.
Because a “group” could indicate the style of line used… again you could have a Group named Construction Lines that’s cormflowerblue / dash / .80mm… it becomes a simple matter of assigning the tool to a group and have it take on the Group pen attributes. I should not that you can always override any attribute.
I think Dark mode has to be an opton. Personally while I don’t know if I’d want to draft in darkmode, I find a “white” bacrground to be tiresome to eyes after awhile. That’s why in my fork I had a “background” color option…
Absolutely. With 1 caveat… presets would be based on the “standard”… for discussion
lets say 10 style items, where there would be a shortcut for each of the 10 items. A user could then create their own custom preset which would have the base 10 items plus any number of custom items. To have shortcuts for custom items we’d have to implement “user” defined shortcuts, and that’s a massive job in of itself to implement.
As in “define” in the prefs a color that indicates an tool / object belongs to more than 1 group? That’s another option. Would actually provide visual feedback indicating it belongs to more than 1 group.
There’s that option too. There’s a routine that checks if an object tool is in a group, amd returns a list of the groups. If the list is NOT empty we can take the 1st item. Which is what I was thinking of.
Also an option… there;s another routine that determines which groups are visible.
That being said… I’m liking the idea of having a multiple group color pref satisfying option 2… which could be Black and satisfy the 1st option. We could also make No Color an option, which if selected as the pref it then falls to selecting the first group in the list satisfying option 3.
The style preset would simply act as a MACRO in that it would set all 3 pen attributes with 1 click / selection. For ex…here’s the toolbar from Cameo: (which uses the opposite terminolgy for Type & Style.)
So we would add a “Style” dropdown to the Pen Toolbar… and add the By Group item to each of the color, linetype, and lineweight dropdowns. So if you want you could customize say a style item Construction lines item to ByGroup / ByGroup / ByGroup so now it would draw by the Group pen for all 3 attributes instead of the tool pen.
Yeeeaaahhh… I’d stay away from black because that would be objects that haven’t been placed in a group yet. (My tuppence worth…) It will make those objects stand out a bit if they’re in the basic default colour.
Just rambling of some questions that are in my mind.
Wouldn’t it be obvious to only be ably to add a tool in the original, then needing it to add to the group the user might want it added to via a right-click option menu? I foresee problems when allowing addition or changing in a group that basically is a mirror image of the original. I suppose it is depended on why you might need groups. One thing I might see a use for is comparing different solutions to a problem without having to untangle several options in the main. Or wouldn’t you present the groups in a different window. Would you want to be able to overlay these groupings?
as to coloring options. It had me think about a software called scribus, which allows you to pre-set a number of ‘styles’ by going into a style-manager. You can create new styles or base a new style on a previous one. (These are text / font based choices mainly) and then later choose to apply them as needed. Something like that, but much simplified, could be of use.
You can also remove an object with the context menu:
You can also move or remove an obect from a group by using the context menu in the Objects dock:
No idea what you mean?
To show or hide various groups in a draft block. Think of Groups as Layers in the normal CAD sense.
Again I don’t know what you mean by “different window.”? Like I said the groups ARE or more less layers. I say more or less as Qt does not support layers, and it would require developing a custom layer framework for the app which is really beyond the scope of wha we need for pattern making. We’re not a CAD application. By selecting which groups are visible in the Groups dock,determines what you see in the main view.
Thanks for your answer. I think I do now better understand what you were talking about. I previously thought groups were meant to be seen as alternatives, which could be viewed in a separate window.
Remaining question: if groups are similar to layers in other software, why wouldn’t you call them layers in Seamly as well? And treat them more the same, like stacks of drawings that are layered (perfect name)?
That being said, having changed other terms, I’m the most aware of what a task it is to completley change a single term. There’s the ui in the docks, dialogs, icon names… all the routines in the cpp & h files, updating the pattern xml schema and writing a conversion routine. Then there’s updating all the translation files. There’s been no big need by users to change the name, so I’m spending my time on other issues. Besides… we are “grouping” objects so the term still in a sense fits.
Odd, I see “Layers” as more likely to involve alternatives. “Groups” are just different items grouped together to be manipulated as a unit in some fashion.
It’s semantics… all layers are gorups but not all groups are layers.
This is what I eventually envision… An Objects Manager tree structure like that in CorelDraw… where objects can be in a group, and objects and groups exist on layers.
BTW… we currently do have “groups” in the typical sense in Seamly2D… they’'re called the Move, Rotate, and Mirror tools - where you group objects together, and perform an opertation on the group.
Sorry to visit this topic again, but I’ve been working on a new basic pattern and have been playing with the line & label colours… which I’ve set to green.
It has been working beautifully, until I started using certain tools which don’t have lines. These labels just revert back to black. Is this intended?
It isn’t really any issue, because I’m going to change them all to black when I’m done, anyway, so this is really just for @Douglas’s FYI.
I love the idea that we will be able to set custom presets, but won’t these be over ridden by the group styles? Perhaps one should choose whether one wants the style presets or the group styles? Then one can approach the matter from there?
