Been working on the Curves dialogs… took a little more experimenting to get the nested layouts to play nice together and allow the textedit box to expand correctly.
New and old for the Curve with fixed control points. Note that updating this dialog also fixed a standing issue with the Linetype which is broken in this tool.
The new and old for the Curve with interactive control points. Also fixes the Linetype issue. Note that the control points are now placed in separate tabs… this will keep the real estate at a minimum when new attributes are eventually added to the dialogs.
I still don’t get the giant equal sign icons.
The new and old Spline with fixed control points I’m thinking a future update to the Spline dialogs is eliminating the dropdown box to change a point in the list and make use of a context menu to edit a point… as well as add & delete points. Fixed the updating when changing a point in the list that was broken.
And the Spline with interactive control points. Again the control points are now placed in separate tabs
I didn’t bother to screencap the Property Editor views for these tools, but it should be noted the Splines with the listview widgets seem to not be implemented in the property Editor, so therefore you can’t edit the points at all. At some point I will either attempt to enable this, or more likely just replace the Property editor with the dialog widgets.
YES! Of course, that wide window wouldn’t fit into the Property Editor sidebar very well, so I’ve just sort of accepted it. Though before I discovered the window the editing options seemed rather lacking!
I think they’re kinda cute! However, as I don’t really notice a difference between your dialogs without the giant equals, & the originals with (unless pointed out,) I don’t think they actually give the additional clarity which seems to be their purpose.
They don’t… they look like another tool button to press - like the = key on a calculator. Besides, 40+ years of forms on a CRT screen have proven all that’s needed is a label and field to enter data.
Well my idea is to eventually remove the Property Editor lib and share the widgets layout between the dialogs and the Editor dock - which is one reason to streamline the dialogs.
In the case of the splines… unlike a curve with only 2 path points, the spline requires the list widget for display of multiple points - which is not implemented as a property in the lib. That’s why you can only edit the color or linetype in the Editor for splines.
All the tool dialogs are updated. Today I worked on updating the “Pattern Piece” dialog. Under the hood I eliminated the “FancyTabBar”… which is the Icon Tabs on the left side of the dialog. The FancyTab just added more bloated code that can done within the form editor in Creator.
First thing you should notice is there is now a “Properties” tab replacing the “Piece Label Data” tab within the Labels page. This is where you will now find the Pattern Piece’s name, and the some of the data used in the Piece Label. I also moved the “Forbid Flipping” checkbox to the Properties page… as it’s NOT a Path function.
The other significant change is the Labels page now splits the “Piece Label” and the “Pattern Label” with separate tabs. A welcome addition here is you will now also be able to edit the “Pattern Label” template here, rather than having to go back into to the Pattern Preferences to edit the template. Imagine that.
Hope moving a few items doesn’t confuse existing users too much.
When you say default template are you referring to a set of default workspace preferences? If so, this is worth investigating… could be handy to be able to save / load any number of preferences. Especially on a machine with multiple users that have their own preferences.
Ahh. OK. I agree one should be able to save a default… or maybe default to “last used” template. This could be a pref - “Use last label template”. Also from the point of view from a new user it can be a bit confusing as to why nothing in the labels show… until you create / load a template. I’ve even got caught wondering why the labels are blank. There should be a default default template.
This brings up another point… that refers back to first time run. If a user does not input any pattern label data in the Pattern Prefs… ie: Author, Company, Client, etc nothing will show in the Pattern Label. A first time splash screen could not only ask for things like default measurement units, it should ask for a minimum amount of pattern label data… which combined with a default default label template - would always a produce a pattern label of sorts.
I’ve worked out some label improvements on my own fork… such as text and background color, so I’ll add improvement of the templates to the list of label improvements to add to Seamly2D.
heh, yeah. I think that as far as a basic, just to prevent confusion template goes, the first four options would be excellent. Using the inputs from your picture of the Properties page above:
Detail
Piece A
Cut 1 on fold
But considering how mooted this point has been, I wasn’t feeling very confident to say anything.
Oh! another option as far as that goes would be to make the label field be visible even when unpopulated. Then it would be clear that it is there though unpopulated.
That would make sense… it would remove one more layer of uncertainty as to why a label is not showing.
That being said… I couldn’t help myself. I added a “Save Default Template” button that automatically saves a template file with either “default_piece_label.xml” or “default_pattern_label.xml” depending on which label is being edited - in the label template dir as set in the prefs., without having to open the file save dialog and typing in a name. Later I’ll use those files - if present , AND if a pref is set to use the default when a new template is created.
Also to be more semantically correct, I changed the dialog title bars to read “Open template” and “Save template” vs “Import label template” and “Export label template”. IMO Import / Export implies using non native files.
I also fixed the issue with the grainline and label anchor points, where if the Top Left / Bottom Right points are used, the Center point (and the width and /or height and rotation) needs to be excluded. Now if you select both a TL and BR anchor the Center anchor and Geometry fields are disabled.
Part of what updating the tool dialogs I’m trying to accomplish is also cleaning up the underlying source code… so it will be easier to add to and maintain. Currently the tool and associated dialog & visualization files are spread across multiple dirs, and in some case 3-4 folders deep. Any time you work on a tool you probably have to access the tool file, the dialog file, and the visual file. Trying to remember where all of each tool’s files is a nightmare the way the code is currently stored while endlessly traversing the file tree in the editor. My idea is to consolidate all of a tool’s files into it’s associated tool group… Points, Lines, Curves, Arcs… Operations… etc. for easier access.
This is what the vtool directory currently somewhat looks like…
It’s a somewhat tedius process to move and rename files - keeping Git, Creator and Atom in sync, but tonight I successfully moved the Operation tools into a vtool->operations folder and got it to compile. Yay! So now it’s MUCH easier to find say the mirror by axis tool files… especially without many of the files prefaced with “v.” The v is going the way of passmarks…
Hopefully. I know it will at least make it easier for myself to access files in the editor. The 1st clue a file structure needs cleaning up is when you’re more than 3 levels deep. VTools itself is already 3 levels deep! I really don’t understand why it seems RT put every new tool into yet another subfolder and put a “v” on almost every file name. < sigh >
Yes, I took 2 months removing all the v’s only to pick up a problem with the vline right at the end. Something else was accessing it, so I kept having to change it back. I eventually gave up.
Yeah, I’ve learned the hard way that changing names and/or case can lead to conflicts. I’ve gotten pretty good at search and replace without messing up the code. Another pet peeve I have in the code styling is the use of capitalized camel case on the method names. RT capitalizes everything, while the Qt style is lower camel case… your brain has to keep flip flopping to figure out if it’s a class or method. It’s even worse because other contributors have used lower case method names. In other words - the code lacks style consistency. IMO, since Qt is the framework used, we should stick to using their naming conventions. Which BTW includes using names like ColorComboBox and color_ComboBox, not ComboBoxColor and comboBoxColor. There’s a few other styling inconsistencies- such as one contributor used Hungarian notation naming conventions - which is just horrid for a well typed language such as c++… but I digress.
Not sure what’s up with prefacing all the classes and filenames with the “V”. It would be like if I chose to replace all the V’s with S’s. I get the use of the Q with Qt classes, as it distinguishes them as part of the framework, but the v’s only makes the code and files less readable. And any good programmer should know 90% of programming is reading code, 10% actual writing code.
Just been tweaking a few of the other dialogs, and finally found the holy hand grenade to eliminate the obstinate unused title bar “?” help button on the file related dialogs - which seem immune to the normal method of dialog->setWindowFlags(…) to turn off the help ?. There’s an app wide setting to disable it for Qt vers 5.10 or newer. Saves about 60 lines of code too. Yea!
Export CSV file dialog with no Mysterion.
Spruced up the Export CSV dialog… and added a new export_csv_icon. “With header” becomes “Include header”… with a slight increase in the font size from 8 to 9 point - like I did with all the other dialogs.
Woo hoo. added one more piece of this puzzle… changed the Properties Editor formula widgets to a QTextEdit from a QLineEdit to be consistent with the tool dialogs. That is, a QTextEdit box is a multi-line word wrapped text box vs the single line QLineEdit. Thought it was going to be way more difficult than it was. Now I just have to figure out where / why the width of the widget is being restricted - probably some margin in the cell is being set. Also need to get it to auto-expand like the dialogs. Not sure yet how easy it would be to place the properties in group boxes - like the dialog’s Selection, Geometry, and Attributes. In a future update I’ll try and figure out how to be able to edit all the properties for a given tool. For example in the tool in the pic you can’t edit the base point.
Finally unraveled the reason for the formula text edit boxes being limited to a smaller size than the other widgets - like the drop down boxes and line edits. Also got the text edit boxes to auto expand like in the dialogs.
: